Affected: graphql-python graphql-core

GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.2.3 until 3.2.12 and 3.3.0rc1, the parser's max_tokens limit in Parser.advance_lexer counts only non-comment tokens returned after Lexer.lookahead skips comments. Each skipped comment is still allocated as a Token and retained through token.next and token.prev, allowing a highly compressible comment-padded GraphQL document to pass a low token limit while consuming memory. An unauthenticated remote attacker can exhaust worker memory before AST-based depth or complexity controls run. This issue is fixed in versions 3.2.12 and 3.3.0rc1.

Affected: PyPI: graphql-core

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