Skip to main content
VulnerabilityPublished Updated

CVE-2026-40324: ChilliCream graphql-platform · Uncontrolled Recursion

Affects ChilliCream graphql-platformSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 9.1 Critical · fixed in 15.1.14 : patch ChilliCream graphql-platform as a priority.

Data as of 30 Oct 2026, 06:59 UTC

CVSS 3.1 base score
9.1Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.9% chance of exploitation in 30 days – higher than 59% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 15.1.14, 14.3.1, 13.9.16 +1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 17 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade graphql-platform to 15.1.14, 14.3.1, 13.9.16 or 12.22.7; ChilliCream/graphql-platform to 12.22.7.

Affected software

ProductAffectedFixed in
ChilliCreamgraphql-platformAffected
  • >=15.0.0 <15.1.14
Fixed in
  • 15.1.14
ChilliCreamgraphql-platformAffected
  • >=14.0.0 <14.3.1
Fixed in
  • 14.3.1
ChilliCreamgraphql-platformAffected
  • >=13.0.0 <13.9.16
Fixed in
  • 13.9.16
ChilliCreamgraphql-platformAffected
  • <12.22.7
Fixed in
  • 12.22.7
NuGetChilliCream/graphql-platformpkg:nuget/ChilliCream/graphql-platformOther threatsAffected
  • <12.22.7
Fixed in
  • 12.22.7

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

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.

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

References

Community reviews

Loading reviews…