ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-75508

GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit

Published Oct 22, 2026 · catalog updated Oct 22, 2026 · Red Hat Red Hat Enterprise Linux

Last checked Nov 4, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-75508. EPSS is 0.57%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.

Same product and reporting

Severity
High7.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.57%
Remediation
Version ranges on file
Affected products
PyPI graphql-core · package pip · pip graphql-core · pypi graphql-core

### Summary The parser's limit — the documented defence against oversized GraphQL documents — did not count comment tokens. A document padded with comments could therefore pass a check of any size while still allocating one 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 in force. ### Details 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 object, and linked into the persistent token list via / — the chain that powers source-location reporting, and which is retained as long as the document is. incremented the token counter only for the tokens the lexer actually returned. Comments were therefore invisible to the accounting, and bounded only the *non-comment* tokens. The practical consequence is a gap between what users reasonably believe 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 ( 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 Measured on GraphQL-core 3.2.8 / CPython 3.12 / Linux x86_64: the 391 KB payload parsed in 127 ms, and the 38.1 MB payload produced an RSS delta of **+92 MB** — about 2.4× the source size, on top of the source string itself. ### Impact Denial of service through memory exhaustion. A modest number of concurrent requests can push a worker past a typical 256 MB or 512 MB container limit and trigger an OOM kill. No authentication is required, and no data is disclosed or modified. Depth limiters and complexity analyzers d

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • PyPI graphql-core3.2.3 → 3.2.12
  • PyPI graphql-core3.3.0a3 → 3.3.0rc1
  • package pipversion unspecified
  • pip graphql-core>= 3.2.3, < 3.2.12
  • pip graphql-core>= 3.3.0a3, < 3.3.0rc1
  • pypi graphql-coreversion unspecified

How to fix CVE-2026-75508

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-75508. EPSS is 0.57%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Which versions are affected?

Compare what you have installed with 3.2.3 → 3.2.12, 3.3.0a3 → 3.3.0rc1, >= 3.2.3, < 3.2.12, >= 3.3.0a3, < 3.3.0rc1. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-400: Uncontrolled Resource Consumption; CWE-770: Allocation of Resources Without Limits or Throttling. EPSS 0.57%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 22, 2026 · Red Hat Security Data

    Detected

    graphql-core: graphql-core: Denial of Service via token limit bypass using comments

  2. Oct 22, 2026 · GitHub Advisory Database

    Updated

    ### Summary The parser's limit — the documented defence against oversized GraphQL documents — did not count comment tokens. A document padded with comments could therefore pass a check of any size while still allocating one 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 wi

  3. Oct 22, 2026 · PyPA Advisory Database

    Fix available

    graphql-core fixed in 3.2.12; graphql-core fixed in 3.3.0rc1

  4. Oct 22, 2026 · PyPA Advisory Database

    Fix available

    graphql-core fixed in 3.2.12

  5. Oct 22, 2026 · PyPA Advisory Database

    Fix available

    graphql-core fixed in 3.3.0rc1

  6. Oct 22, 2026 · PyPA Advisory Database

    Updated

    ### Summary The parser's limit — the documented defence against oversized GraphQL documents — did not count comment tokens. A document padded with comments could therefore pass a check of any size while still allocating one 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 wi

Sources

  • CVE.orgVulnerability recordCVE-2026-75508

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-75508

    30-day exploitation probability 0.57%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-r77w-qph3-7vf8

    GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit

    github.com
  • GitLab Advisory DatabasePackage advisoryCVE-2026-75508

    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 re

    advisories.gitlab.com
  • PyPA Advisory DatabasePackage advisoryGHSA-r77w-qph3-7vf8

    GraphQL-core: Denial of service via comment tokens bypassing the parser's max_tokens limit

    osv.dev
  • Red Hat Security DataVendor advisoryCVE-2026-75508

    graphql-core: graphql-core: Denial of Service via token limit bypass using comments

    access.redhat.com
  • Snyk Vulnerability DatabasePackage advisorySNYK-PYTHON-GRAPHQLCORE-21433569

    Allocation of Resources Without Limits or Throttling

    security.snyk.io

References

Freshness

Last verified in this catalog Nov 4, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • FIRST EPSSNov 4, 2026
  • Snyk Vulnerability DatabaseOct 25, 2026
  • GitHub Advisory DatabaseOct 23, 2026
  • PyPA Advisory DatabaseOct 23, 2026
  • GitLab Advisory DatabaseOct 23, 2026
  • Red Hat Security DataOct 23, 2026
  • CVE.orgOct 23, 2026