CVE-2026-75508

What it actually does

The GraphQL parser's max_tokens limit only counts non-comment tokens after Lexer.lookahead skips comments, yet each skipped comment allocates a retained Token object linked via next/prev pointers, allowing a low token budget to trigger unbounded memory allocation before AST depth or complexity checks execute.

Why it matters to the business

An unauthenticated remote attacker can crash GraphQL worker processes with a single crafted request, causing service outages and requiring restarts; the issue is only four days old with no known exploits but demands immediate attention due to its low-effort remote impact on any service exposing the vulnerable parser.

How an attack unfolds

An attacker crafts a GraphQL document containing many highly compressible comments to exceed memory while staying under the configured max_tokens value; the parser allocates and links Token objects for every comment before any later validation occurs, exhausting worker memory and denying service to legitimate clients.

How to fix it

Upgrade GraphQL-core to version 3.2.12 or 3.3.0rc1 or later; if immediate upgrade is impossible, enforce strict request size limits at the web server or proxy and monitor memory usage of GraphQL workers.

How to confirm the fix worked

Confirm the installed package version is 3.2.12 or higher, then test that a comment-padded document exceeding the prior memory threshold is now rejected at the lexer stage without excessive allocation.

Typical attack path

1. Identify an unauthenticated GraphQL endpoint using the vulnerable parser version
2. Generate a minimal request containing a large number of comments that compresses well
3. Send the request to bypass the token limit and trigger repeated Token allocations
4. Observe worker process memory growth until exhaustion and service failure

How to detect it

Inspect web server and application logs for unusually large GraphQL requests containing high comment-to-token ratios; correlate with worker process memory spikes or OOM events shortly after request receipt.

What your security team should do

• Apply the fixed versions immediately given the four-day publication window
• Add WAF or proxy rules limiting GraphQL request body size and comment density
• Enable runtime memory and CPU alerts on GraphQL worker processes
• Review downstream dependents for inherited exposure and schedule upgrades