CVE-2026-119286 in graphql-core
Summary
by MITRE • 10/30/2026
GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.3.0a3 until 3.3.1, validate() reuses a module-level ValidationAbortedError when a document exceeds max_errors. Python appends frames to the reused exception's traceback on every raise, retaining each document, validation context, and error set for the process lifetime. An unauthenticated client can repeatedly submit a small document with more than 100 validation errors to cause unbounded memory growth before query execution, eventually exhausting worker memory without disclosing or modifying data. This issue is fixed in version 3.3.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within the GraphQL-core library represents a significant resource exhaustion risk stemming from improper exception handling during document validation. GraphQL-core serves as a Python implementation of the GraphQL.js reference, facilitating structured query processing for web applications. The core issue resides in the validate() function's behavior when it encounters documents that exceed the configured max_errors threshold. Specifically, between versions 3.3.0a3 and 3.3.1, the library reuses a single module-level ValidationAbortedError instance rather than creating new exception objects for each validation failure. This design choice was likely intended to optimize performance or reduce object allocation overhead but inadvertently introduced a severe memory leak mechanism that can be exploited by attackers.
From a technical perspective, Python's traceback generation process appends stack frames to the exception object every time it is raised and caught. Because GraphQL-core reuses the same ValidationAbortedError instance across multiple validation cycles within the same request or even across different requests if the worker persists, each raise operation adds new frame data to that single object. Consequently, the exception's traceback grows indefinitely as long as the error condition persists. This results in unbounded memory growth because the garbage collector cannot reclaim the memory associated with the growing traceback and its references to document contexts, validation states, and error sets. The retained objects accumulate over time, leading to a steady increase in RAM consumption by the application process hosting the GraphQL endpoint.
The operational impact of this vulnerability is primarily denial of service through resource exhaustion. An unauthenticated attacker can exploit this flaw by repeatedly submitting small GraphQL documents that are designed to trigger more than 100 validation errors per request. Since the memory leak occurs during the validation phase, which precedes query execution, the attack does not require successful data retrieval or modification capabilities. The victim application will eventually consume all available worker memory, causing crashes, service unavailability, or degraded performance for legitimate users. This type of attack is particularly dangerous in serverless environments or applications with limited memory quotas, where a single malicious request can terminate an entire execution container due to the OOM killer triggering prematurely.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-772, Missing Release of Resource after Effective Lifetime, given that the resources associated with the traceback are not released properly during repeated use of the same exception object. In terms of attack vectors, this falls under ATT&CK technique T1496, Resource Hijacking, where an attacker consumes system resources to degrade service availability without necessarily compromising data integrity or confidentiality. The lack of authentication requirement makes it a high-risk vulnerability for public-facing GraphQL APIs that do not implement strict rate limiting on validation-heavy endpoints.
Mitigation strategies focus primarily on upgrading the library version immediately if running within the affected range, as this issue was resolved in version 3.3.1 by ensuring proper isolation of exception states or preventing traceback accumulation across reuse cycles. For applications unable to upgrade instantly, implementing robust input validation and rate limiting at the network edge can help mitigate the impact by restricting the frequency of requests that trigger excessive validation errors. Additionally, configuring application servers with memory limits and automatic restart policies on OOM events can provide a layer of defense against complete service outages while longer-term fixes are deployed. Developers should also consider reviewing their GraphQL configuration to ensure max_errors is set appropriately for their use case, balancing security needs with performance expectations to minimize the window of opportunity for such resource exhaustion attacks.