CVE-2026-40476

graphql-go is a Go implementation of GraphQL. In versions 15.31.4 and below, the OverlappingFieldsCanBeMerged validation rule performs O(n²) pairwise comparisons of fields sharing the same response name. An attacker can send a query with thousands of repeated identical fields, causing excessive CPU usage during validation before execution begins. This is not mitigated by existing QueryDepth or QueryComplexity rules. This issue has been fixed in version 15.31.5.

graphql-go is a Go implementation of GraphQL. In versions 15.31.4 and below, the OverlappingFieldsCanBeMerged validation rule performs O(n²) pairwise comparisons of fields sharing the same response name. An attacker can send a query with thousands of repeated identical fields, causing excessive CPU usage during validation before execution begins. This is not mitigated by existing QueryDepth or QueryComplexity rules. This issue has been fixed in version 15.31.5.

The OverlappingFieldsCanBeMerged validation rule exhibits quadratic time complexity when processing queries with many repeated fields sharing the same response name. An attacker can send a crafted query like { hello hello hello ... } with thousands of repeated fields, causing excessive CPU usage during validation before execution begins.

This is not mitigated by existing QueryDepth or QueryComplexity rules.

Observed impact (tested on v15.31.4):

• 1000 fields: ~0.6s
• 2000 fields: ~2.4s
• 3000 fields: ~5.3s
• 5000 fields: request timeout (>20s)

Root cause: collectConflictsWithin() performs O(n²) pairwise comparisons of all fields with the same response name. For identical repeated fields, every comparison returns "no conflict" but the quadratic iteration count causes resource exhaustion.

Fix: Deduplicate structurally identical fields before pairwise comparison, reducing the complexity from O(n²) to O(u²) where u is the number of unique field signatures (typically 1 for this attack pattern).

Credit: Ashwak N ([email protected])

Summary

OverlappingFieldsCanBeMerged validation rule has O(n^2 x m^2) worst case via flattened inline fragments. The CVE-2023-26144 named-fragment cache does not cover inline fragments. A 364 KB query (200 outer x 100 inner inline fragments) consumes 117 seconds of CPU per request, with no comparison budget and no validation timeout.

Affected Component

src/Validator/Rules/OverlappingFieldsCanBeMerged.php

Description

graphql-php is a PHP port of graphql-js and inherits the same OverlappingFieldsCanBeMerged algorithm. The rule performs an explicit O(n^2) pairwise comparison loop over fields collected for each response name (collectConflictsWithin), and recurses into sub-selections via findConflict. When the rule receives a query in which several inline fragments select the same response name at multiple nesting levels, the cost compounds to O(n^2 x m^2) where n and m are the number of inline fragments at the outer and inner levels respectively.

graphql-php includes a comparedFragmentPairs PairSet cache (the same class of memoization fix tracked under CVE-2023-26144 / GHSA-9pv7-vfvm-6vr7), but it is keyed by named fragment identity. Inline fragments have no name; they are flattened into the parent $astAndDefs map by the case $selection instanceof InlineFragmentNode branch starting at OverlappingFieldsCanBeMerged.php:266, so they are never observed by the cache. Every pair must be re-compared from scratch on every nesting level.

This finding has been tested against the latest stable release webonyx/[email protected] running on PHP 8.3.30.

Root Cause

1. Pairwise O(n^2) loop (collectConflictsWithin)

// src/Validator/Rules/OverlappingFieldsCanBeMerged.php:306
$fieldsLength = count($fields);

if ($fieldsLength > 1) {
    for ($i = 0; $i < $fieldsLength; ++$i) {                             // line 311
        for ($j = $i + 1; $j < $fieldsLength; ++$j) {                    // line 312
            $conflict = $this->findConflict(
                $context,
                $parentFieldsAreMutuallyExclusive,
                $responseName,
                $fields[$i],
                $fields[$j]
            );
            // ...
        }
    }
}

count($fields) grows without bound when multiple inline fragments select the same response name in the same parent selection set.

2. Inline fragment flattening (internalCollectFieldsAndFragmentNames)

// src/Validator/Rules/OverlappingFieldsCanBeMerged.php:266
case $selection instanceof InlineFragmentNode:
    $typeCondition = $selection->typeCondition;
    $inlineFragmentType = $typeCondition === null
        ? $parentType
        : AST::typeFromAST([$context->getSchema(), 'getType'], $typeCondition);

    $this->internalCollectFieldsAndFragmentNames(
        $context,
        $inlineFragmentType,
        $selection->selectionSet,
        $astAndDefs,           // flattened into the parent map
        $fragmentNames
    );
    break;

N inline fragments selecting the same response name produce N entries in $astAndDefs[$responseName], which then trigger N*(N-1)/2 findConflict calls.

3. The named-fragment cache does not cover this code path

// src/Validator/Rules/OverlappingFieldsCanBeMerged.php:41
protected PairSet $comparedFragmentPairs;

// :54 (in __construct)
$this->comparedFragmentPairs = new PairSet();

PairSet is keyed by (fragmentName1, fragmentName2). Inline fragments have no name; they are folded into the parent selection set before the cache is even consulted. The CVE-2023-26144 fix has zero effect on this code path.

4. No comparison budget, no validation timeout

There is no counter shared across collectConflictsWithin, collectConflictsBetween, and the recursive findConflict calls. The rule runs to completion regardless of cost. graphql-php exposes no validate_timeout equivalent.

Proof…

Summary

GraphQL\Language\Parser is a recursive descent parser with no recursion depth limit and no zend.max_allowed_stack_size interaction. Crafted nested queries trigger a SIGSEGV in the PHP runtime, killing the FPM/CLI worker process. Smallest crashing payload is approximately 74 KB.

Affected Component

• src/Language/Parser.php -- the Parser class (no recursion depth tracking)
• src/Language/Lexer.php -- the Lexer class

Severity

HIGH (8.2) -- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

Integrity is Low because the entire PHP process (FPM worker, CLI process, Swoole worker, RoadRunner worker, etc.) is terminated by SIGSEGV. Every concurrent request handled by the same process is dropped along with the attacker's request, with no error message, no log entry, and no recovery path beyond restart. The 74 KB minimum crashing payload sits well below any common HTTP body size limit, and the failure mode is the worst possible: not catchable, not observable, no diagnostics.

Description

GraphQL\Language\Parser parses GraphQL documents using mutually recursive PHP methods (parseValueLiteral, parseObject, parseObjectField, parseList, parseSelectionSet, parseSelection, parseField, parseTypeReference, parseInlineFragment). The constructor (Parser.php:325) accepts only three options:

// src/Language/Parser.php:64
/**
 * @phpstan-type ParserOptions array{
 *   noLocation?: bool,
 *   allowLegacySDLEmptyFields?: bool,
 *   allowLegacySDLImplementsInterfaces?: bool,
 * }
 */

There is no maxTokens, no maxDepth, no maxRecursionDepth, no token counter, and no recursion depth counter anywhere in the parser or lexer. PHP recursion is bounded only by the C stack size (typically 8 MB via ulimit -s 8192).

When the C stack is exhausted by graphql-php's recursive parser, PHP segfaults. The PHP 8.3 runtime ships with zend.max_allowed_stack_size (default 0 = auto-detect), which is supposed to convert userland recursion overflow into a catchable Stack overflow detected error. In practice, this protection does not catch the graphql-php parser overflow: testing with PHP 8.3.30 in default Docker configuration, every crashing depth produces SIGSEGV (exit code 139), not a catchable error.

This finding has been tested against the latest stable release webonyx/[email protected] running on PHP 8.3.30.

Root Cause

// src/Language/Parser.php:168
class Parser
{
    // ... no recursionDepth field ...
    private Lexer $lexer;

    // src/Language/Parser.php:325
    public function __construct($source, array $options = [])
    {
        $sourceObj = $source instanceof Source
            ? $source
            : new Source($source);
        $this->lexer = new Lexer($sourceObj, $options);
    }

There is no field tracking recursion depth. Every recursive parse method calls itself without bound. PHP function call frames are small (~256 bytes each), but the cumulative depth needed by recursive descent for a GraphQL value literal exhausts an 8 MB stack at approximately 26,000-37,000 levels of input nesting (depending on the call chain depth per AST level).

Proof of Concept

// composer require webonyx/graphql-php:v15.31.4
<?php
require __DIR__.'/vendor/autoload.php';
use GraphQL\Language\Parser;

// Each invocation tests one (vector, depth) pair so we can observe per-process
// exit code. SIGSEGV cannot be caught by PHP try/catch.
$v = $argv[1]; $d = (int)$argv[2];

switch ($v) {
    case 'A': $q = "{ a(x: " . str_repeat('{a: ', $d) . '1' . str_repeat('}', $d) . ") }"; break;
    case 'B': $q = str_repeat('{ a', $d) . str_repeat(' }', $d); break;
    case 'C': $q = "{ a(x: " . str_repeat('[', $d) . '1' . str_repeat(']', $d) . ") }"; break;
    case 'D': $q = "query(\$v: " . str_repeat('[', $d) . "Int" . str_repeat(']', $d) . ") { a }"; break;
}

try {
    Parser::parse($q);
    echo "OK depth=$d size=" . strlen($q) . "\n";
} catch…

graphql-go is a Go implementation of GraphQL. In versions 15.31.4 and below, the OverlappingFieldsCanBeMerged validation rule performs O(n²) pairwise comparisons of fields sharing the same response name. An attacker can send a query with thousands of repeated identical fields, causing excessive CPU usage during validation before execution begins. This is not mitigated by existing QueryDepth or QueryComplexity rules. This issue has been fixed in version 15.31.5.