CVE-2026-75507

What it actually does

The OverlappingFieldsCanBeMerged validation rule in GraphQL-core performs repeated pairwise comparisons of fields sharing response names and recursively re-expands flattened inline fragments without memoization for this case, yielding quadratic to O(n²·m²) CPU consumption on specially crafted queries before any resolver or depth/complexity limits execute.

Why it matters to the business

An unauthenticated attacker can send a compact GraphQL query that exhausts CPU on one or more worker processes, causing request backlogs, timeouts, or full service unavailability for legitimate users; the recent publication and stable EPSS indicate low immediate mass-exploitation risk but still require prompt patching to avoid targeted denial-of-service.

How an attack unfolds

An attacker crafts a shallow GraphQL document containing many nested inline fragments that share response names, submits it over HTTP or WebSocket to any exposed endpoint, and forces the server-side validation phase to perform repeated field-merging work that consumes a worker thread until the process is pinned or the service saturates.

How to fix it

Upgrade GraphQL-core to 3.2.12 or 3.3.0rc1 (or later) in all environments; if immediate upgrade is blocked, place strict query-size, depth, and complexity limits in front of the GraphQL layer or disable the affected validation rule until patched.

How to confirm the fix worked

After upgrade, send the previously crashing query and confirm validation completes in linear time with no CPU spike; scan dependency manifests (requirements.txt, Pipfile, poetry.lock, etc.) for any remaining graphql-core versions older than 3.2.12 / 3.3.0rc1.

Typical attack path

1. Identify an unauthenticated GraphQL endpoint accepting queries
2. Generate or copy a compact query with deeply nested repeated inline fragments sharing response names
3. Submit the query via POST or GET to trigger validation
4. Observe sustained high CPU on the worker and degraded or lost availability for other requests
5. Repeat or parallelize queries to amplify resource exhaustion

How to detect it

Search web-server and application logs for GraphQL POST bodies containing many nested inline fragments or unusually long fragment spreads; correlate with worker-process CPU or memory spikes that lack corresponding resolver activity.

What your security team should do

• Immediately inventory all Python services using graphql-core and schedule upgrade to 3.2.12 or 3.3.0rc1 within the next maintenance window
• Add GraphQL query-complexity and depth middleware if not already present
• Monitor CPU and request-latency metrics on GraphQL workers for anomalous sustained load
• Block or rate-limit unauthenticated GraphQL queries from untrusted networks until patched