---
id: CVE-2026-75507
aliases:
  - GHSA-vj8h-fx38-h3vc
title: >-
  GraphQL-core: Denial of service via quadratic complexity in the
  OverlappingFieldsCanBeMerged validation rule
summary: >-
  GraphQL-core: Denial of service via quadratic complexity in the
  OverlappingFieldsCanBeMerged validation rule
severity: high
cvss: 7.5
cwe:
  - CWE-400
  - CWE-407
vendor: graphql-core
product: graphql-core
ecosystem: pip
affected:
  - 'graphql-core >= 3.0.0, < 3.2.12'
  - 'graphql-core >= 3.3.0a1, < 3.3.0rc1'
patched:
  - graphql-core 3.2.12
  - graphql-core 3.3.0rc1
published: '2026-10-22'
updated: '2026-10-22'
sourceUpdated: '2026-10-22T16:26:42Z'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-vj8h-fx38-h3vc'
references:
  - url: >-
      https://github.com/graphql-python/graphql-core/security/advisories/GHSA-vj8h-fx38-h3vc
  - url: >-
      https://github.com/graphql-python/graphql-core/commit/150e59814d97d12140be005a558c93188ef89198
  - url: >-
      https://github.com/graphql-python/graphql-core/commit/29c2753a7ee30a96a4109e7c6add1a2dae0497d7
  - url: 'https://github.com/graphql-python/graphql-core/releases/tag/v3.2.12'
  - url: 'https://github.com/graphql-python/graphql-core/releases/tag/v3.3.0rc1'
  - url: 'https://github.com/advisories/GHSA-vj8h-fx38-h3vc'
tags:
  - ghsa
  - pip
  - cve.org
ingestedAt: '2026-10-22T22:00:50.254Z'
---

## Overview

### Summary

The `OverlappingFieldsCanBeMerged` validation rule can be driven into quadratic — and
in the worst case `O(n²·m²)` — 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. Because the rule is part of `specified_rules`
and therefore enabled by default, every GraphQL-core based server is affected at
default settings.

### Details

`OverlappingFieldsCanBeMerged` compares every pair of fields that share a response
name and recurses into their sub-selections. The memoization added for
CVE-2023-26144 (`GHSA-9pv7-vfvm-6vr7`) is keyed by **named fragment** identity, so it
does not cover this path: inline fragments are flattened into the parent selection
set before the cache is consulted, and therefore every pair is re-compared from
scratch at every nesting level.

Repeating an inline fragment that selects the same response name at two nesting
levels multiplies the two effects. There was no comparison budget and no validation
timeout, so the rule ran to completion regardless of cost.

The cost is incurred in the **validation phase**, which is what makes this hard to
defend against from outside the library: query-depth limiters, complexity analyzers
and cost estimators all operate on the parsed document *after* validation, and the
malicious document is trivially shallow (depth 3, complexity 1). The payload is also
one short string repeated many times, so it compresses to a few kilobytes and slips
past body-size limits and WAF inspection that only see the compressed request.

### Proof of concept

```python
import time
from graphql import build_schema, parse, validate

schema = build_schema(
    "type Query { field: Node } type Node { f: Node, g: Node, x: String }"
)

def gen(n: int, m: int) -> str:
    inner = " ".join(["... on Node { x }"] * m)
    outer = " ".join([f"... on Node {{ f {{ {inner} }} }}"] * n)
    return f"{{ field {{ {outer} }} }}"

query = gen(200, 100)          # 364 KB, gzips to a few KB
document = parse(query)
start = time.perf_counter()
validate(schema, document)      # returns no errors — it just burns CPU
print(f"{(time.perf_counter() - start):.0f}s")
```

Measured on GraphQL-core 3.2.8 / CPython 3.12 / Linux x86_64:

| n | m | query size | validation time |
|---|---|---|---|
| 20 | 20 | 7.6 KB | 0.16 s |
| 50 | 50 | 46 KB | 5.2 s |
| 100 | 100 | 182 KB | 81 s |
| 200 | 100 | 364 KB | **319 s** |

Doubling `n` at fixed `m` quadruples the time, as expected for a quadratic outer loop
driving a quadratic inner walk.

### Impact

Denial of service. One request pins one worker process for minutes; because CPython
holds the GIL for this pure-CPU work, a handful of concurrent requests can saturate a
typical multi-worker deployment. No authentication is required, and no data is
disclosed or modified.

### Patches

Fixed in **3.2.12** and **3.3.0rc1**.

Validation now enforces a per-document comparison budget. Once
`MAX_FIELD_COMPARISONS` (default `250_000`) pairwise comparisons have been made, the
rule aborts and reports a `GraphQLError` instead of running to completion:

> Query is too complex to validate for overlapping fields: exceeded 250000 field
> comparisons. Validation was aborted.

The default is far above what any realistic query reaches. It is a module-level
constant and can be raised or lowered:

```python
from graphql.validation.rules import overlapping_fields_can_be_merged

overlapping_fields_can_be_merged.MAX_FIELD_COMPARISONS = 1_000_000
```

Note the behaviour change: a pathological query that previously validated — slowly —
now produces a validation error.

### Workarounds

If you cannot upgrade, reject oversized documents before they reach `validate()`.
Note that a request body-size limit must be applied to the **decompressed** body to be
effective here, since the payload is highly compressible. Removing
`OverlappingFieldsCanBeMergedRule` from the rule set is *not* a safe workaround: it is
a correctness rule required by the specification.

A body-size limit remains worthwhile after upgrading — the comparison budget bounds
this specific rule, not overall request cost.

### Credits

Reported by @BZHunt, who also reviewed the fixes
before release. In memory of ZaX, who was the driving force behind this discovery.

Independently found and diagnosed by @bcmyguest, who
also proposed a fix.

## Affected packages

- `graphql-core >= 3.0.0, < 3.2.12`
- `graphql-core >= 3.3.0a1, < 3.3.0rc1`

## Remediation

Upgrade to a patched release:

- `graphql-core 3.2.12`
- `graphql-core 3.3.0rc1`