CVE-2026-40324: CWE-674: Uncontrolled Recursion in ChilliCream graphql-platform
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 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).
AI Analysis
Technical Summary
Hot Chocolate's Utf8GraphQLParser in affected versions has no recursion depth limit, enabling crafted GraphQL documents with deeply nested selection sets or values to trigger a StackOverflowException. Because .NET does not allow catching StackOverflowException, the entire worker process terminates immediately, dropping all active HTTP requests, background tasks, and WebSocket subscriptions. This occurs before any validation or complexity checks, so existing GraphQL validation rules cannot prevent the crash. The vulnerability affects versions prior to 12.22.7, 13.9.16, 14.3.1, and 15.1.14. The patch adds a MaxAllowedRecursionDepth option to ParserOptions, enforcing recursion limits and throwing catchable SyntaxExceptions instead of crashing. There is no application-level workaround; only upgrading to patched versions fully mitigates the issue. Limiting HTTP request body size at proxies can reduce but not eliminate risk due to the small size and compressibility of crashing payloads.
Potential Impact
Exploitation causes a StackOverflowException that immediately terminates the .NET worker process running the GraphQL server. This results in denial of service by dropping all in-flight HTTP requests, background hosted service tasks, and open WebSocket subscriptions on that process. The process must be restarted by the orchestrator, causing service disruption. There is no impact on confidentiality or data integrity reported. The vulnerability cannot be mitigated by GraphQL validation rules because the crash occurs before validation. The CVSS score is 9.1 (critical) reflecting high impact on availability.
Mitigation Recommendations
A fix is available in Hot Chocolate versions 12.22.7, 13.9.16, 14.3.1, and 15.1.14 that adds a recursion depth limit to the parser and prevents stack overflow crashes. Operators should upgrade to these patched versions to fully mitigate the vulnerability. There is no application-level workaround because StackOverflowException cannot be caught in .NET. Operators can reduce risk by limiting HTTP request body size at reverse proxies or load balancers, but this is not sufficient to prevent crashes due to the small size and compressibility of malicious payloads. Patch status is not explicitly stated in the vendor advisory content provided, but the version numbers indicate official fixes are released.
CVE-2026-40324: CWE-674: Uncontrolled Recursion in ChilliCream graphql-platform
Description
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 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).
CVSS v3.1
Score 9.1critical
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Hot Chocolate's Utf8GraphQLParser in affected versions has no recursion depth limit, enabling crafted GraphQL documents with deeply nested selection sets or values to trigger a StackOverflowException. Because .NET does not allow catching StackOverflowException, the entire worker process terminates immediately, dropping all active HTTP requests, background tasks, and WebSocket subscriptions. This occurs before any validation or complexity checks, so existing GraphQL validation rules cannot prevent the crash. The vulnerability affects versions prior to 12.22.7, 13.9.16, 14.3.1, and 15.1.14. The patch adds a MaxAllowedRecursionDepth option to ParserOptions, enforcing recursion limits and throwing catchable SyntaxExceptions instead of crashing. There is no application-level workaround; only upgrading to patched versions fully mitigates the issue. Limiting HTTP request body size at proxies can reduce but not eliminate risk due to the small size and compressibility of crashing payloads.
Potential Impact
Exploitation causes a StackOverflowException that immediately terminates the .NET worker process running the GraphQL server. This results in denial of service by dropping all in-flight HTTP requests, background hosted service tasks, and open WebSocket subscriptions on that process. The process must be restarted by the orchestrator, causing service disruption. There is no impact on confidentiality or data integrity reported. The vulnerability cannot be mitigated by GraphQL validation rules because the crash occurs before validation. The CVSS score is 9.1 (critical) reflecting high impact on availability.
Mitigation Recommendations
A fix is available in Hot Chocolate versions 12.22.7, 13.9.16, 14.3.1, and 15.1.14 that adds a recursion depth limit to the parser and prevents stack overflow crashes. Operators should upgrade to these patched versions to fully mitigate the vulnerability. There is no application-level workaround because StackOverflowException cannot be caught in .NET. Operators can reduce risk by limiting HTTP request body size at reverse proxies or load balancers, but this is not sufficient to prevent crashes due to the small size and compressibility of malicious payloads. Patch status is not explicitly stated in the vendor advisory content provided, but the version numbers indicate official fixes are released.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-04-10T21:41:54.505Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 69e2c0dabdfbbecc599fc03e
Added to database: 4/17/2026, 11:23:06 PM
Last enriched: 4/25/2026, 2:51:03 AM
Last updated: 6/2/2026, 7:43:09 AM
Views: 188
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.