graphql-core CVE-2026-75507 quadratic validation flaw patches released for CPU exhaustion fix

The graphql-core library contains a high-severity vulnerability that enables attackers to cause severe CPU exhaustion. This flaw exists in the default validation rules used by most GraphQL servers built with this Python package.

What happened

The vulnerability, tracked as CVE-2026-75507, resides in the OverlappingFieldsCanBeMerged validation rule within graphql-core. According to the GitHub advisory GHSA-vj8h-fx38-h3vc, this rule can be driven into quadratic running time by a small, highly compressible query. A single 364 KB document can occupy one CPU core for over five minutes during validation, before any resolver runs.

The issue arises because the rule compares every pair of fields sharing a response name and recurses into sub-selections. The memoization added for CVE-2023-26144 is keyed by named fragment identity, which does not cover inline fragments. Inline fragments are flattened into the parent selection set before the cache is consulted, causing every pair to be re-compared from scratch at every nesting level.

Repeating an inline fragment that selects the same response name at two nesting levels multiplies these effects. There was no comparison budget or validation timeout, so the rule ran to completion regardless of cost. The cost is incurred in the validation phase, making it hard to defend against from outside the library.

Why it matters

Query-depth limiters, complexity analyzers, and cost estimators typically operate on the parsed document after validation. The malicious document in this case is trivially shallow, with a depth of 3 and a complexity of 1. Consequently, standard defense mechanisms do not intervene before the computational cost is incurred.

The payload is also one short string repeated many times, allowing it to compress to a few kilobytes. This compression allows the request to slip past body-size limits and web application firewall inspection that only sees the compressed request. Because the rule is part of specified_rules and enabled by default, every graphql-core based server is affected at default settings.

What to watch

• Monitor for sudden spikes in CPU utilization on GraphQL endpoints that do not correlate with increased traffic volume.
• Check server logs for validation errors or unusually long request durations that occur before resolver execution.
• Review firewall logs for small, highly compressed payloads that bypass standard size-based filtering rules.

Signals worth monitoring

Teams usually detect this type of validation-phase exhaustion by observing sustained high CPU usage on application nodes handling GraphQL requests. Security operations centers should check whether existing alerts trigger on total request duration, as the malicious activity occurs before business logic runs. Analysts typically look for patterns where small, compressed requests result in disproportionate processing times. Containment moves often involve temporarily limiting request sizes at the network edge or implementing strict timeouts for the validation phase to prevent prolonged resource locking.

What to do and how to stay safe: graphql-core

• Upgrade graphql-core to version 3.2.12 or 3.3.0rc1 to apply the confirmed fix.
• Implement strict timeouts for the GraphQL validation phase to limit the window for CPU exhaustion.
• Configure web application firewalls to inspect decompressed request bodies to detect small payloads that expand significantly.
• Review server configuration to ensure validation rules are not running without cost limits or budgets.

General security guidance from the Firewall Chronicle newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of graphql-core are vulnerable to CVE-2026-75507?

Versions 3.0.0 through 3.2.11 and versions 3.3.0a1 through 3.3.0rc0 are vulnerable.

Is a patch available for this vulnerability?

Yes, patches are available in version 3.2.12 and version 3.3.0rc1.

Why do standard GraphQL defenses fail to stop this attack?

The attack occurs during validation, before depth limiters and complexity analyzers operate, and the payload is shallow and compressible.