Affected: Homebrew: moto

### 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 c…

GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.0.0 until 3.2.12 and 3.3.0rc1, the OverlappingFieldsCanBeMerged rule in specified_rules repeatedly compares fields that share response names and recursively re-compares flattened inline fragments during the validation phase. The prior named-fragment memoization does not cover this path, so nested repeated inline fragments can drive quadratic and worst-case O(n²·m²) CPU work before any resolver or AST-based depth or complexity control runs. An unauthenticated remote attacker can submit a shallow, highly compressible GraphQL query that pins a worker process and can saturate a multi-worker service. This issue is fixed in versions 3.2.12 and 3.3.0rc1.

Affected: PyPI: graphql-core

### 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 c…

Affected: Ubuntu:22.04:LTS: graphql-core, Ubuntu:24.04:LTS: graphql-core, Ubuntu:26.10: graphql-core, Ubuntu:26.04:LTS: graphql-core

GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.0.0 until 3.2.12 and 3.3.0rc1, the OverlappingFieldsCanBeMerged rule in specified_rules repeatedly compares fields that share response names and recursively re-compares flattened inline fragments during the validation phase. The prior named-fragment memoization does not cover this path, so nested repeated inline fragments can drive quadratic and worst-case O(n²·m²) CPU work before any resolver or AST-based depth or complexity control runs. An unauthenticated remote attacker can submit a shallow, highly compressible GraphQL query that pins a worker process and can saturate a multi-worker service. This issue is fixed in versions 3.2.12 and 3.3.0rc1.