EUVD-2026-45304
GHSA-3w5p-95mh-gq75
Severity by source
AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network vector and no-privilege access apply when NCalc evaluates untrusted input via an API; only availability is impacted - no confidentiality or integrity effect.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
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.
AnalysisAI
Denial-of-service via unbounded factorial evaluation affects NCalc (NCalc.Core and NCalcSync NuGet packages) prior to v6.1.1, allowing remote attackers to exhaust CPU resources or trigger non-terminating computation loops by submitting expressions with extremely large factorial operands such as 9223372036854775807! (Int64.MaxValue). The root cause is CWE-190 integer overflow in MathHelper.cs's factorial calculation logic, which previously lacked bounds validation, allowing operands well beyond any representable result to be passed directly to the computation loop. No public exploit or CISA KEV listing has been identified at time of analysis, though the triggering expressions are trivially constructable and documented in the advisory itself.
Technical ContextAI
NCalc is a .NET mathematical expression evaluation library distributed as NuGet packages (pkg:nuget/ncalc.core and pkg:nuget/ncalcsync). The vulnerability resides in NCalc.Core/Helpers/MathHelper.cs within the Factorial() dispatch method, which prior to v6.1.1 passed all numeric types (int, long, float, double, decimal, BigInteger) directly to CalculateFactorial<T>() without bounds checking. CWE-190 (Integer Overflow or Wraparound) applies because computing 9223372036854775807! (Int64.MaxValue) overflows the loop counter or intermediate accumulator, causing the evaluation to enter a non-terminating or runaway computation state rather than returning a bounded error. The fix in PR #575 introduces a MaxFactorialInput constant capped at 170 (the largest integer whose factorial fits in a double) and a ValidateFactorialInput<T>() gate that rejects negative values, NaN, infinity, and any operand exceeding 170 before the computation begins. Tests were added to assert ArgumentOutOfRangeException for all formerly dangerous inputs.
RemediationAI
Upgrade NCalc.Core and NCalcSync to v6.1.1 or later, which contains the bounds-validation fix from PR #575 (https://github.com/ncalc/ncalc/pull/575). The fix introduces a hard cap of 170 on factorial operands, rejecting larger values with ArgumentOutOfRangeException before any computation occurs. If immediate upgrade is not feasible, three compensating controls are documented in the advisory: first, restrict expression evaluation exclusively to trusted, internal sources - this fully eliminates the attack surface but requires application-level input provenance controls. Second, add an expression pre-validation layer that detects and rejects factorial tokens (e.g., regex matching on large numeric literals followed by '!') before passing expressions to NCalc; this adds latency and maintenance burden and may reject legitimate large-but-safe operands if thresholds are set conservatively. Third, wrap all NCalc evaluation calls in execution time limits or CancellationToken-based timeouts (e.g., Task.Run with a 1-5 second timeout); this bounds the DoS window but does not prevent resource consumption from concurrent attacks, and introduces complexity around partial-evaluation cleanup. None of the workarounds fully address the root cause - patching to v6.1.1 is the only complete fix.
Same weakness CWE-190 – Integer Overflow or Wraparound
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today