What is the CVSS score of CVE-2026-40324?

CVE-2026-40324 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Hot Chocolate are affected by CVE-2026-40324?

ChilliCream's Hot Chocolate GraphQL server (.NET library) contains an unauthenticated remote denial-of-service vulnerability that enables attackers to crash worker processes via crafted GraphQL…. A patch is available.

How to fix or mitigate CVE-2026-40324?

Within 24 hours: Identify all systems running HotChocolate.Language package, particularly those serving internet-facing GraphQL endpoints, and consult the vendor advisory for the specific patch version applicable to your deployment. Within 7 days: Deploy the vendor-released patch to staging for validation, then to all production instances prioritizing internet-facing GraphQL endpoints, maintaining rollback capability in case of unexpected regressions. Within 30 days: Implement GraphQL request depth monitoring and rate limiting, establish alerting for suspicious query patterns, and verify patch compliance enterprise-wide to prevent reintroduction of the vulnerability.

Hot Chocolate CVE-2026-40324

CRITICAL

Uncontrolled Recursion (CWE-674)

2026-04-16 https://github.com/ChilliCream/graphql-platform

GHSA-qr3m-xw4c-jqw3

Denial Of Service Kubernetes

9.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

vuln.today AI

7.5 HIGH

Unauthenticated network attacker sends a trivial crafted document (PR:N/UI:N/AC:L); impact is a process-crash DoS only, so C:N/I:N and A:H, differing from the published I:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jul 24, 2026 - 07:20 vuln.today

Analysis Generated

Jul 24, 2026 - 07:20 vuln.today

Patch released

Apr 16, 2026 - 21:15 nvd

Patch available

CVE Published

Apr 16, 2026 - 21:09 nvd

CRITICAL 9.1

DescriptionGitHub Advisory

Impact

Hot Chocolate's Utf8GraphQLParser is a recursive descent parser with no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or 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 existing MaxAllowedFields=2048 limit does not help because the crashing payloads contain very few fields.

Severity: Critical (9.1) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Patches

v12 line: Fixed in 12.22.7
v13 line: Fixed in 13.9.16
v14 line: Fixed in 14.3.1
v15 line: Fixed in 15.1.14

The fix 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.

Workarounds

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).

References

Fix for v15: https://github.com/ChilliCream/graphql-platform/pull/9528

AnalysisAI

Unauthenticated remote denial-of-service in ChilliCream's Hot Chocolate GraphQL server for .NET (HotChocolate.Language package) lets any client crash the entire worker process by sending a small, deeply nested GraphQL document. Because the recursive-descent Utf8GraphQLParser has no depth limit, ~40 KB of nested selection sets, object/list values, or list types triggers an uncatchable StackOverflowException that terminates the process, dropping all in-flight HTTP requests, IHostedService background tasks, and WebSocket subscriptions on that worker. No public exploit identified at time of analysis and EPSS is low (0.09%), but the attack is trivial (AC:L, PR:N) and CISA SSVC flags it as automatable, so it is a practical availability threat to internet-facing GraphQL endpoints.

Technical ContextAI

Hot Chocolate is the dominant open-source GraphQL server framework for the .NET/ASP.NET Core ecosystem; the flaw lives in its HotChocolate.Language parsing library (all four affected CPEs point to pkg:nuget/hotchocolate.language). The root cause is CWE-674 (Uncontrolled Recursion): Utf8GraphQLParser is a hand-written recursive-descent parser whose methods (ParseSelectionSet, ParseValueLiteral, ParseObject, ParseList, ParseTypeReference) call themselves once per level of syntactic nesting, consuming a stack frame each time. With no ceiling on nesting depth, an attacker-controlled document forces recursion until the CLR thread stack is exhausted. Critically, .NET has treated StackOverflowException as non-catchable and non-recoverable since .NET 2.0, so it cannot be handled with try/catch and fast-fails the whole process. The parse step also runs before validation, so existing GraphQL defenses (MaxExecutionDepth, complexity analyzers, persisted-query allow-lists, MaxAllowedFields=2048, custom IDocumentValidatorRule) never execute. The vendor fix introduces a MaxAllowedRecursionDepth ParserOptions setting (default 200) enforced across all recursive parser methods, converting the overflow into a catchable SyntaxException.

RemediationAI

Vendor-released patch: upgrade HotChocolate.Language (and dependent HotChocolate packages) to the fixed release for your line - 12.22.7, 13.9.16, 14.3.1, or 15.1.14 - which adds the MaxAllowedRecursionDepth ParserOptions limit (default 200) and throws a catchable SyntaxException instead of overflowing the stack. Patched releases are at https://github.com/ChilliCream/graphql-platform/releases/tag/15.1.14 (and the equivalent 12.22.7 / 13.9.16 / 14.3.1 tags); the fix PR is https://github.com/ChilliCream/graphql-platform/pull/9528 and advisory GHSA-qr3m-xw4c-jqw3. There is no true application-level workaround because StackOverflowException cannot be caught in .NET and the parser runs before any validation rule. As a partial compensating control, cap HTTP request body size at the reverse proxy or load balancer (e.g. nginx client_max_body_size, an ingress annotation, or IIS maxAllowedContentLength) to well under the observed 40 KB crashing payload; note the trade-off that legitimate large queries or batched operations may be rejected, and that this does not eliminate risk since 40 KB is small, highly compressible (a few hundred bytes gzipped), and below most default limits. Consider running GraphQL workers in a Kubernetes/IIS configuration that restarts crashed processes quickly and isolates blast radius, but understand this only limits, not prevents, the outage - upgrading is the only real fix.