Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:HSummary
CVE-2026-40324 is a critical-severity Uncontrolled Recursion (CWE-674) vulnerability. Its CVSS base score is 9.1 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked in the top 43% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and SC-5 (Denial-of-service Protection) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-40324 affects Hot Chocolate, an open-source GraphQL server for .NET, specifically versions prior to 12.22.7, 13.9.16, 14.3.1, and 15.1.14. The vulnerability resides in the recursive descent parser `Utf8GraphQLParser`, which lacks a recursion depth limit. A crafted GraphQL document featuring deeply nested selection sets, object values, list values, or list types—possible with payloads as small as 40 KB—triggers a `StackOverflowException`. This exception is uncatchable in .NET, causing immediate termination of the entire worker process and disrupting all in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions.
The attack requires no authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, score 9.1) and can be executed by any remote attacker with network access to the GraphQL endpoint. Exploitation occurs before validation rules like `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, or custom `IDocumentValidatorRule` implementations, as `Utf8GraphQLParser.Parse` runs first. The `MaxAllowedFields=2048` limit is ineffective against these payloads, which contain few fields. Successful exploitation results in denial of service, forcing the orchestrator (e.g., Kubernetes, IIS) to restart the process.
Patched versions 12.22.7, 13.9.16, 14.3.1, and 15.1.14 introduce a `MaxAllowedRecursionDepth` option in `ParserOptions` with a safe default, enforced across recursive methods like `ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, and `ParseTypeReference`. Exceeding the limit throws a catchable `SyntaxException` instead of stack overflow. There is no application-level workaround, as `StackOverflowException` cannot be caught; upgrading is required. Operators can partially mitigate by limiting HTTP request body size at reverse proxies or load balancers, though the 40 KB payloads are compressible to a few hundred bytes via gzip and often below defaults. Fix details are in GitHub commits such as 08c0caa42ca33c121bbed49d2db892e5bf6fb541 and pull request #9528.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-23579
Vulnerability Data
Hot Chocolate is an open-source GraphQL server. Prior to versions 12.22.7, 13.9.16, 14.3.1, and 15.1.14, Hot Chocolate's recursive descent parser `Utf8GraphQLParser` has no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or…
more
list types can trigger a `StackOverflowException` on payloads as small as 40 KB. Because `StackOverflowException` is uncatchable in .NET (since .NET 2.0), the entire worker process is terminated immediately. All in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions on that worker are dropped. The orchestrator (Kubernetes, IIS, etc.) must restart the process. This occurs before any validation rules run — `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, and custom `IDocumentValidatorRule` implementations cannot intercept the crash because `Utf8GraphQLParser.Parse` is invoked before validation. The `MaxAllowedFields=2048` limit does not help because the crashing payloads contain very few fields. The fix in versions 12.22.7, 13.9.16, 14.3.1, and 15.1.14 adds a `MaxAllowedRecursionDepth` option to `ParserOptions` with a safe default, and enforces it across all recursive parser methods (`ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, `ParseTypeReference`, etc.). When the limit is exceeded, a catchable `SyntaxException` is thrown instead of overflowing the stack. There is no application-level workaround. `StackOverflowException` cannot be caught in .NET. The only mitigation is to upgrade to a patched version. Operators can reduce (but not eliminate) risk by limiting HTTP request body size at the reverse proxy or load balancer layer, though the smallest crashing payload (40 KB) is well below most default body size limits and is highly compressible (~few hundred bytes via gzip).
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Input validation can reject or constrain data that would otherwise drive unbounded recursive calls.
DoS protection mechanisms limit the resource-exhaustion impact of uncontrolled recursion without eliminating the flaw.
System monitoring can observe anomalous resource consumption that signals runaway recursion after it begins.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent coding errors such as missing recursion limits or termination conditions.
Runtime monitoring of compute resources can detect excessive consumption caused by uncontrolled recursion.
Vulnerability identification processes can discover and record uncontrolled recursion flaws before deployment.
Capacity monitoring and resource provisioning can absorb or limit the impact of runaway recursion.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect excessive recursion via static analysis or fuzzing.
Secure development life cycle requires controls that prevent uncontrolled recursion through design and code review.
Application security requirements can mandate recursion limits or stack-depth checks.
Secure system architecture principles include resource-management and input-validation rules that limit recursion.
Secure coding standards directly prohibit or constrain recursive constructs that could exhaust stack or memory.
Capacity management includes monitoring and limits that mitigate resource exhaustion from runaway recursion.