GraphQL-core EUVD-2026-108225

Affects any application that passes untrusted client input to graphql-core's parse() (the parser underlying Graphene, Strawberry, Ariadne and similar Python GraphQL servers) in versions >=3.2.3 and <3.2.12, or >=3.3.0a3 and <3.3.0rc1. No special feature or non-default configuration is required - remote unauthenticated exploitation works against default setups, and critically the bug is NOT mitigated by the usual defense: setting max_tokens does not stop it, because comment tokens were excluded from the count (that exclusion IS the vulnerability). AST-based depth and complexity limiters also do not help, since they run only after parsing succeeds. The main amplifying precondition is that the server decompresses request bodies (gzip) before parsing, so body-size limits or WAF inspection applied to the compressed request do not observe the true payload size. Limiting factors: impact is confined to availability (memory exhaustion / OOM of the worker); effectiveness depends on the worker/container memory ceiling and request concurrency; and a request body-size limit enforced on the DECOMPRESSED body before parse() blocks it. Per the vendor, upgrading is the complete fix, and note the behavior change that comments now count toward max_tokens.

This is a credible but bounded availability risk, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U, C:N/I:N/A:H, base 7.5) is internally consistent with the description: an unauthenticated remote attacker sends a single crafted GraphQL document over the network with no user interaction and no special timing, and the only impact is availability (memory exhaustion / OOM) - confidentiality and integrity are explicitly untouched. The vuln.today decision label is 'this_week' rather than act_now/emergency, which fits a DoS with no data impact. No EPSS score and no CISA KEV status were supplied, so exploitation probability and active-exploitation signals cannot be weighed - the absence of these is a data gap, not evidence of low risk. A working proof-of-concept is embedded in the GitHub Security Advisory (GHSA-r77w-qph3-7vf8) demonstrating the max_tokens bypass and ~2.4x memory amplification, so the technique is public and trivially reproducible, though it is a resource-exhaustion demonstrator rather than a code-execution weapon. The notable risk amplifier is that the flaw defeats the very control (max_tokens) operators rely on, and that AST-level depth/complexity limiters run only after parsing, so common GraphQL hardening does not mitigate it. Net: a real priority worth patching promptly for any internet-facing Python GraphQL service, but its ceiling is denial of service, and the lack of KEV/EPSS suggests no confirmed widespread exploitation at time of analysis.

An unauthenticated attacker sends a GraphQL endpoint a small, highly compressible document consisting of hundreds of thousands of comment lines (e.g. '

c\n' repeated) followed by a trivial query like '{ a }'. Because comments were not counted toward max_tokens, the document passes the parser's size guard, but each comment is still allocated as a persistent Token object, so a ~38 MB decompressed payload consumes roughly +92 MB of resident memory; a handful of concurrent requests push a worker past typical 256-512 MB container limits and trigger an OOM kill. A public proof-of-concept demonstrating this is included in the GHSA advisory.