CVE-2026-75508

### 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