CVE-2026-75507 in graphql-core
Summary
by MITRE • 10/23/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within the graphql-core library represents a significant algorithmic complexity flaw located specifically within the OverlappingFieldsCanBeMerged validation rule. This component of the GraphQL execution engine is responsible for ensuring that fields requested in a query do not conflict with one another, thereby maintaining data integrity and consistency during resolution. In versions ranging from 3.0.0 through 3.2.12 and including version 3.3.0rc1, the implementation fails to efficiently handle scenarios involving nested inline fragments that share response names. The core technical deficiency lies in the recursive comparison logic used to validate these overlapping fields. Instead of leveraging existing memoization techniques effectively for this specific code path, the validator repeatedly re-evaluates flattened inline fragments. This lack of optimization means that as the depth and complexity of nested structures increase, the computational effort required does not scale linearly but rather exhibits quadratic behavior relative to the number of fields involved.
This algorithmic inefficiency results in a worst-case time complexity of O(n squared times m squared), where n and m represent variables related to the query structure size. Such exponential growth in CPU consumption allows an unauthenticated remote attacker to craft a specifically designed GraphQL query that appears superficially simple but contains highly compressible nested structures. When this malicious payload is processed, it forces the server-side worker processes to engage in excessive computational work during the validation phase. Crucially, this resource exhaustion occurs before any subsequent security controls, such as AST-based depth limiting or complexity scoring mechanisms, are able to intervene and reject the request based on its structural properties. Consequently, a single malicious query can effectively pin a CPU core for an extended period, leading to severe performance degradation across the entire service if multiple workers are affected simultaneously.
The operational impact of this vulnerability is primarily centered around denial-of-service conditions that compromise the availability of GraphQL API services. By saturating worker processes with computationally expensive validation tasks, attackers can render legitimate user requests unresponsive or significantly delayed. This type of attack exploits the trust placed in the input validation layer to perform necessary checks without considering the cost of those checks themselves. The vulnerability aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-770, Allocation of Resources Without Limits or Throttling. From a threat intelligence perspective, this behavior is consistent with ATT&CK technique T1496, Resource Hijacking, where adversaries leverage computational resources to disrupt service availability rather than stealing data directly.
Mitigation for this issue requires an immediate upgrade to graphql-core version 3.2.12 or later, specifically including the release candidate 3.3.0rc1 and subsequent stable releases which address the memoization gap in the OverlappingFieldsCanBeMerged rule. For organizations unable to patch immediately due to dependency constraints, implementing strict input validation at the network perimeter is advisable. This includes deploying Web Application Firewalls configured to detect and block GraphQL queries with excessive nesting depth or unusually high field overlap patterns. Additionally, enforcing query complexity analysis tools that operate prior to standard validation can help filter out potentially malicious payloads before they reach the vulnerable code path within graphql-core. Regular auditing of third-party dependencies for algorithmic vulnerabilities is essential to maintain robust defense-in-depth strategies against such resource exhaustion attacks.