Summary
GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit
The parser's max_tokens limit, the documented defence against oversized GraphQL
documents, did not count comment tokens. A document padded with comments could
therefore pass a max_tokens check of any size while still allocating one Token
object per comment, all of which stay reachable for the lifetime of the parsed
document. A 38 MB comment-padded payload allocated roughly 92 MB of additional
resident memory with max_tokens=5 in force.
Details
Lexer.lookahead() reads tokens one at a time and skips over comments, returning only
the first non-comment token. Each skipped comment is nevertheless fully tokenized,
allocated as a Token object, and linked into the persistent token list viatoken.next / token.prev, the chain that powers source-location reporting, and
which is retained as long as the document is.
Parser.advance_lexer() incremented the token counter only for the tokens the lexer
actually returned. Comments were therefore invisible to the accounting, andmax_tokens bounded only the non-comment tokens.
The practical consequence is a gap between what users reasonably believe max_tokens
protects and what it did protect. The limit was not broken for ordinary documents ,
real tokens were still capped correctly, so the shortfall was not observable without
specifically testing comment padding.
As with the companion issue, the payload compresses extremely well (# c\n repeated),
so body-size limits and WAF inspection applied to the compressed request do not see
its true size, while the framework decompresses it in memory before the parser is
reached.
Proof of concept
import gc
import resource
from graphql import parse
# 100,000 comments, a 5-token query, and max_tokens=5, accepted.
query = "# c\n" * 100_000 + "{ a }"
parse(query, max_tokens=5) # no error raised
# Memory amplification.
big = "# padding comment used to amplify memory per token\n" * 500_000 + "{ a }"
gc.collect()
before = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
parse(big, max_tokens=5) # ~38 MB source
after = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(f"RSS delta: +{(after - before) / 1024:.0f} MB")
Measured on GraphQL-core 3.2.8 / CPython 3.12 / Linux x86_64: the 391 KB payload
parsed in 127 ms, and the 38.1 MB payload produced an RSS delta of +92 MB, about
2.4× the source size, on top of the source string itself.
Workarounds
If you cannot upgrade, apply a request body-size limit to the decompressed body
before the document reaches parse().
Such a limit is worth keeping after upgrading as well: max_tokens is one guard among
several and bounds the token count, not the overall cost of a request.
References
- GraphQL specification § 2.1.4, Comments
Credits
Reported by @BZHunt, who also reviewed the fixes
before release. In memory of ZaX, who was the driving force behind this discovery.
Impact
Denial of service through memory exhaustion. A modest number of concurrent requests
can push a worker past a typical 256 MB or 512 MB container limit and trigger an
OOM kill. No authentication is required, and no data is disclosed or modified.
Depth limiters and complexity analyzers do not help: they run on the AST after parsing
has already succeeded, and the document contains only five real tokens.
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
CVE-2026-75508 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.2.12, 3.3.0rc1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 3.2.12 and 3.3.0rc1.
Parser.advance_lexer now counts every token consumed, including the comment tokens
the lexer skips between the previously focused token and the new one, and including
the advance onto EOF so that trailing comments are covered. max_tokens therefore now
bounds every Token the parser allocates.
Note the behaviour change: comments now count toward max_tokens. A
comment-heavy document that was previously accepted may now be rejected. If you parse
documents containing substantial comments, SDL files with documentation comments, for
instance, and you set max_tokens, you may need to raise the limit. Thetoken_count attribute of a parsed document likewise now includes comments.
Frequently Asked Questions
- What is CVE-2026-75508? CVE-2026-75508 is a high-severity uncontrolled resource consumption vulnerability in graphql-core (pip), affecting versions >= 3.2.3, < 3.2.12. It is fixed in 3.2.12, 3.3.0rc1. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- How severe is CVE-2026-75508? CVE-2026-75508 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of graphql-core are affected by CVE-2026-75508? graphql-core (pip) versions >= 3.2.3, < 3.2.12 is affected.
- Is there a fix for CVE-2026-75508? Yes. CVE-2026-75508 is fixed in 3.2.12, 3.3.0rc1. Upgrade to this version or later.
- Is CVE-2026-75508 exploitable, and should I be worried? Whether CVE-2026-75508 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-75508 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-75508?
- Upgrade
graphql-coreto 3.2.12 or later - Upgrade
graphql-coreto 3.3.0rc1 or later
- Upgrade