Skip to content

← Public intelligence

Packagist package

webonyx/graphql-php

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.2PackagistPublished

    webonyx/graphql-php has unbounded recursion in parser that causes stack overflow on crafted nested input

    GHSA-r7cg-qjjm-xhqq

    Affected
    • Packagist webonyx/graphql-php <= 15.32.2
    Fixed in
    15.32.3· Vendor fix available
    Issue
    GraphQL\Language\Parser is a recursive descent parser with no recursion depth limit and no zend.maxallowedstacksize 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…

    Recommended action: Upgrade to 15.32.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.5PackagistPublished

    webonyx/graphql-php has quadratic validation cost in OverlappingFieldsCanBeMerged via inline fragments

    GHSA-fc86-6rv6-2jpm

    Affected
    • Packagist webonyx/graphql-php < 15.32.2
    Fixed in
    15.32.2· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 15.32.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Medium, CVSS 6.9PackagistPublished

    graphql-php is affected by a Denial of Service via quadratic complexity in OverlappingFieldsCanBeMerged validation

    CVE-2026-40476 · GHSA-68jq-c3rv-pcrr

    Affected
    • Packagist webonyx/graphql-php <= 15.31.4
    Fixed in
    15.31.5· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 15.31.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →