NCalc: Denial of Service via Unbounded and Non-Terminating Factorial Evaluation
Description
Impact
A denial-of-service (DoS) vulnerability exists in the factorial operator implementation of NCalc. Specially crafted expressions containing extremely large factorial operands can trigger excessive CPU consumption or cause evaluation to enter a non-terminating loop due to integer overflow in the factorial calculation logic.
Applications that evaluate untrusted expressions using affected versions of NCalc may be vulnerable to resource exhaustion, potentially resulting in service disruption or application unresponsiveness.
This issue can be triggered with expressions such as:
99999999999999!
9223372036854775807!
1.5e16!
Patches
The vulnerability has been fixed by adding bounds validation for factorial operands and rejecting unsupported values before evaluation.
Users should upgrade to the first release containing the fix from pull request #575. (v6.1.1+)
Workarounds
If upgrading is not immediately possible:
- Do not evaluate expressions originating from untrusted users.
- Validate or sanitize expressions before evaluation and reject factorial operations on large values.
- Implement execution time limits, request timeouts, or cancellation mechanisms around expression evaluation.
These mitigations may reduce exposure but do not fully address the underlying vulnerability.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"Missing upper-bound validation on factorial operands allows integer overflow and unbounded loop iteration."
Attack vector
An attacker submits a specially crafted expression containing a factorial operator with an extremely large operand (e.g., `99999999999999!`, `9223372036854775807!`, or `1.5e16!`). The NCalc evaluation engine passes this operand directly into the factorial calculation loop without any upper-bound validation, causing excessive CPU consumption or a non-terminating loop due to integer overflow. This can be done over any network path that delivers untrusted expressions to the application, and no authentication is required if the expression evaluation endpoint is publicly accessible. [patch_id=6467596]
What the fix does
The patch introduces a constant `MaxFactorialInput = 170` and a family of `ValidateFactorialInput` overloads that reject any factorial operand exceeding this bound before the calculation loop begins. Previously, only a negative check existed; the loop would iterate up to the attacker-supplied value, causing resource exhaustion. The new validation throws `ArgumentOutOfRangeException` immediately for values above 170, NaN, or infinity, preventing the expensive or non-terminating loop from executing. [patch_id=6467596]
Preconditions
- configThe application must evaluate untrusted expressions using an affected version of NCalc.
- inputThe attacker must be able to supply a factorial expression with an operand greater than 170.
- authNo authentication is required if the evaluation endpoint is publicly accessible.
- networkThe expression is delivered over any network path the application listens on.
Generated on Jun 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.