https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 28 Oct 2026 16:49:04 +0000 https://db.gcve.eu/vuln/brew-moto-cve-2026-75508 <p><strong>Affected:</strong> Homebrew: moto</p> <p>### Summary</p> <p>The parser&#39;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.</p> <p>### Details</p> <p>`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.</p> <p>`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.</p> <p>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.</p> <p>As with the companion issue, the payload compresses extremely well (`# c\n` repeated), so body-size limits and WAF inspection applied to…</p> <p><strong>Affected:</strong> Homebrew: moto</p> <p>### Summary</p> <p>The parser&#39;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.</p> <p>### Details</p> <p>`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.</p> <p>`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.</p> <p>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.</p> <p>As with the companion issue, the payload compresses extremely well (`# c\n` repeated), so body-size limits and WAF inspection applied to…</p> https://db.gcve.eu/vuln/brew-moto-cve-2026-75508 https://db.gcve.eu/vuln/fkie_cve-2026-75508 <p>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&#39;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.</p> <p>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&#39;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.</p> https://db.gcve.eu/vuln/fkie_cve-2026-75508 https://db.gcve.eu/vuln/ghsa-r77w-qph3-7vf8 <p><strong>Affected:</strong> PyPI: graphql-core</p> <p>### Summary</p> <p>The parser&#39;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.</p> <p>### Details</p> <p>`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.</p> <p>`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.</p> <p>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.</p> <p>As with the companion issue, the payload compresses extremely well (`# c\n` repeated), so body-size limits and WAF inspection applied to…</p> <p><strong>Affected:</strong> PyPI: graphql-core</p> <p>### Summary</p> <p>The parser&#39;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.</p> <p>### Details</p> <p>`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.</p> <p>`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.</p> <p>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.</p> <p>As with the companion issue, the payload compresses extremely well (`# c\n` repeated), so body-size limits and WAF inspection applied to…</p> https://db.gcve.eu/vuln/ghsa-r77w-qph3-7vf8 https://db.gcve.eu/vuln/ubuntu-cve-2026-75508 <p><strong>Affected:</strong> Ubuntu:22.04:LTS: graphql-core, Ubuntu:24.04:LTS: graphql-core, Ubuntu:26.10: graphql-core, Ubuntu:26.04:LTS: graphql-core</p> <p>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&#39;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.</p> <p><strong>Affected:</strong> Ubuntu:22.04:LTS: graphql-core, Ubuntu:24.04:LTS: graphql-core, Ubuntu:26.10: graphql-core, Ubuntu:26.04:LTS: graphql-core</p> <p>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&#39;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.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-75508