High-severity GraphQL-core flaw causes severe CPU exhaustion in default server setups

The graphql-core Python library contains a high-severity flaw that allows attackers to exhaust CPU resources on servers using default configuration settings. According to GitHub advisory GHSA-vj8h-fx38-h3vc, the issue stems from the OverlappingFieldsCanBeMerged validation rule, which is enabled by default in specified_rules. This rule is responsible for checking query structure before execution, making it a critical entry point for resource exhaustion attacks.

How it unfolded

• Researchers identified that the validation rule could be driven into quadratic running time by small, highly compressible queries.
• The flaw was assigned CVE-2026-75507 and rated as high severity due to the ease of exploitation and impact on availability.
• The graphql-core maintainers released patch version 3.2.12 to address the issue in the 3.2 branch.
• A concurrent fix was issued in version 3.3.0rc1 for the development branch, closing the vulnerability in both major release lines.

Who is affected

Any organization running graphql-core version 3.0.0 up to but not including 3.2.12 is vulnerable. Additionally, systems using versions from 3.3.0a1 up to but not including 3.3.0rc1 are also affected. The vulnerability exists because the memoization added for a previous issue, CVE-2023-26144, was keyed by named fragment identity. This approach failed to cover inline fragments, which are flattened into the parent selection set before the cache is consulted. Consequently, every pair of fields is re-compared from scratch at every nesting level, leading to significant performance degradation.

Our take on the response

The availability of patches in both the 3.2 and 3.3 release branches allows administrators to remediate the issue quickly without needing to switch major versions. The fact that the vulnerability resides in the validation phase, rather than the resolver phase, makes it particularly dangerous because standard query-depth limiters and complexity analyzers operate after validation. This means the malicious document is processed fully before those safeguards can intervene, highlighting the importance of library-level fixes over application-layer mitigations for this specific class of flaw.

Who needs to act first

Managed service providers should prioritize updating systems that expose GraphQL endpoints directly to the internet or untrusted internal networks. Teams usually begin by identifying all instances of the vulnerable graphql-core versions across their infrastructure. Before rolling out the update, it is advisable to test the patched version in a staging environment to ensure compatibility with existing applications. Organizations should also back up their current configurations and application states to allow for quick rollback if unexpected issues arise during the deployment process.

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

• Audit your Python environments to identify any installations of graphql-core versions 3.0.0 through 3.2.11 or 3.3.0a1 through 3.3.0rc1.
• Upgrade affected systems to version 3.2.12 or 3.3.0rc1 as soon as possible to mitigate the risk of CPU exhaustion.
• Monitor server CPU usage and validation times for unusual spikes that could indicate attempts to exploit the quadratic complexity flaw.
• Review your WAF and body-size limit configurations, as the malicious payload is small and compressible, potentially bypassing these controls.

Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time

General security guidance from the Patch Observer 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 up to 3.2.11 and versions 3.3.0a1 up to 3.3.0rc1 are vulnerable.

Is there a patch available for this vulnerability?

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

Why do standard query limiters fail to stop this attack?

The cost is incurred during the validation phase, which occurs before query-depth limiters and complexity analyzers operate on the parsed document.