GHSA-r77w-qph3-7vf8 - GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit
### Summary
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 via
`token.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, and
`max_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
```python
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 = resou
HIGH
Severity & confidence
Source severityhigh
Platform severityhigh
Confidenceconfirmed
Exploitationunknown
CVSS7.5
Affected
Vendorsgraphql-coreRed Hat
Productsgraphql-core
Reporting sources (3)
GitHub Security Advisories
Red Hat - CVE Feed
NIST NVD - National Vulnerability Database
Timeline & provenance
Published2026-10-22T16:27:14
Last updated2026-10-25T02:26:21
Ingested2026-10-22T16:38:06
FreshnessNEAR-REAL-TIME
Threat typeadvisory
Recommended action
Review the advisory and upgrade affected packages to the first patched version.
Next steps
- Identify affected systems in your environment.
- Apply the vendor patch or mitigation guidance.
- Review logs for indicators described in the advisory.
- Follow the affected vendor/product to track updates.
Confidence explanation
This object is reported by 3 independent sources.
Source type: vendor ยท Original: GitHub Security Advisories