Hot Chocolate patches stack-overflow DoS in GraphQL parser

TL;DR — Hot Chocolate’s unbounded recursive GraphQL parser can be crashed remotely with a small deeply nested document, terminating the .NET worker process and dropping in-flight requests.

What happened

Hot Chocolate is an open-source GraphQL server for .NET (part of ChilliCream’s GraphQL Platform) used to expose GraphQL APIs over HTTP and WebSockets.

CVE-2026-40324 describes a Critical (CVSS 3.1 9.1) denial-of-service issue: Hot Chocolate’s recursive descent parser (Utf8GraphQLParser) had no recursion depth limit, so an unauthenticated attacker can send a deeply nested GraphQL document that triggers a StackOverflowException with payloads reported as small as ~40 KB.

Operationally, this is worse than a typical “slow request” DoS because StackOverflowException is uncatchable in .NET, so the entire worker process terminates immediately, dropping in-flight HTTP requests, background IHostedService tasks, and open WebSocket subscriptions; your orchestrator (e.g., Kubernetes/IIS) then has to restart the process. The CVE notes this happens before validation rules run, so mechanisms like MaxExecutionDepth, complexity analyzers, persisted-query allowlists, and custom validation rules don’t intercept the crashing payload.

Why it matters: parser-depth / recursion-limit failures are a repeatable “one request, one crash” reliability vulnerability class, and GraphQL endpoints are frequently internet-exposed or reachable by semi-trusted clients where request-shaping attacks are realistic.

Who is impacted

• Any deployment exposing a Hot Chocolate GraphQL endpoint to untrusted or semi-trusted clients (internet-facing APIs, mobile clients, partner integrations), especially where worker restarts cause visible downtime or message-loss.
• Affected versions (per CVE record):

What to do now

• Follow vendor remediation guidance and apply a patched Hot Chocolate release.

  "The only mitigation is to upgrade to a patched version."

• Inventory where Hot Chocolate is deployed (services, containers, serverless) and map running versions to the affected ranges; prioritize internet-exposed GraphQL endpoints.
• If you cannot patch immediately, use compensating controls that reduce exposure while you schedule an upgrade:
  • Enforce GraphQL endpoint protections at the edge (WAF / API gateway / reverse proxy), and consider stricter request handling for the GraphQL route.
  • Add or tighten HTTP request body size limits at the reverse proxy / load balancer layer (the CVE notes this can reduce but not eliminate risk, and the smallest crashing payload is reported as ~40 KB and highly compressible).
• Treat repeated worker restarts or bursts of StackOverflowException-style crashes as potential exploitation signals; correlate GraphQL request logs (including compressed size vs. decompressed size, if available) with restarts and dropped connections.