GraphQL-core Comment Padding Bypasses Token Limits in High Severity Flaw

The graphql-core Python library contains a high severity vulnerability that allows attackers to bypass configured token limits. The flaw, identified as CVE-2026-75508, stems from how the parser handles comment tokens within GraphQL documents. Users who relied on the max_tokens setting to prevent resource exhaustion found that this defense did not account for comments. This gap enables attackers to craft payloads that appear small to the token counter but consume significant memory resources during parsing.

Root cause

The parser’s max_tokens limit was designed to defend against oversized GraphQL documents by capping the number of tokens processed. However, this limit did not count comment tokens during validation. The Lexer.lookahead() method reads tokens individually and skips over comments, returning only the first non-comment token. Despite being skipped for logical processing, each comment is fully tokenized and allocated as a Token object. These objects are linked into a persistent token list via token.next and token.prev pointers, which support source-location reporting.

Attack path

Because the token counter only incremented for non-comment tokens, comments remained invisible to the max_tokens accounting mechanism. An attacker could pad a valid GraphQL document with thousands of comments, allowing it to pass a strict max_tokens check while still allocating memory for every single comment. The proof of concept demonstrates that a query with 100,000 comments and max_tokens set to 5 was accepted without error. This discrepancy between the perceived safety of the limit and its actual coverage created an exploitable gap.

Affected versions

The vulnerability affects specific ranges of the graphql-core package distributed via pip. Version 3.2.3 and later versions up to, but not including, 3.2.12 are vulnerable. Similarly, version 3.3.0a3 and later versions up to, but not including, 3.3.0rc1 are affected. Users running these versions should verify their installed dependencies to determine if they fall within these ranges. The issue was resolved in the subsequent patched releases mentioned in the advisory.

Mitigation

Users should update their graphql-core installations to the patched versions immediately. For the 3.2.x branch, version 3.2.12 contains the fix. For the 3.3.x branch, version 3.3.0rc1 addresses the vulnerability. These updates ensure that comment tokens are correctly counted toward the max_tokens limit, restoring the intended protection against oversized documents. Teams should verify that their deployment pipelines pull the latest secure versions of the library.

Signals worth monitoring

Security operations teams should monitor for unusual memory spikes in services processing GraphQL queries, especially when request sizes appear small. Check application logs for parsing errors or delays that correlate with high memory usage. Look for requests containing large numbers of comment characters or repetitive patterns that might indicate padding attacks. Implement alerts for processes that exceed expected memory thresholds during query parsing. Review access logs for any anomalous query structures that bypass standard validation checks but cause performance degradation.

What to do and how to stay safe: graphql-core

• Update graphql-core to version 3.2.12 or 3.3.0rc1 to apply the vendor-provided fix for CVE-2026-75508.
• Review current max_tokens configurations to ensure they are set to reasonable limits that reflect actual memory constraints.
• Monitor server memory usage closely after applying updates to verify that comment-padded payloads no longer cause exhaustion.
• Consider implementing additional input validation at the network edge to reject requests with unusually high comment-to-content ratios.

Step-by-step guide: Attack Surface Management: 6 Common Misreadings and Correct Views

General security guidance from the NetSec Observer newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of graphql-core are vulnerable to CVE-2026-75508?

Versions 3.2.3 through 3.2.11 and 3.3.0a3 through 3.3.0rc1 are vulnerable to this high severity flaw.

How does the vulnerability allow attackers to bypass token limits?

The max_tokens limit did not count comment tokens, allowing attackers to pad documents with comments that consumed memory without triggering the limit.

Is there a patch available for this vulnerability?

Yes, patches are available in graphql-core versions 3.2.12 and 3.3.0rc1, which correct the token counting logic.