CVE-2026-75508 in graphql-core
Summary
by MITRE • 10/23/2026
GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.2.3 until 3.2.12 and 3.3.0rc1, the parser's max_tokens limit in Parser.advance_lexer counts only non-comment tokens returned after Lexer.lookahead skips comments. Each skipped comment is still allocated as a Token and retained through token.next and token.prev, allowing a highly compressible comment-padded GraphQL document to pass a low token limit while consuming memory. An unauthenticated remote attacker can exhaust worker memory before AST-based depth or complexity controls run. This issue is fixed in versions 3.2.12 and 3.3.0rc1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within the GraphQL-core library, specifically affecting versions from 3.2.3 through 3.2.12 and version 3.3.0rc1, represents a critical resource exhaustion flaw rooted in the implementation of the lexer's token counting mechanism. GraphQL-core serves as a Python port of the official JavaScript reference implementation for GraphQL, aiming to provide robust parsing capabilities for query documents. However, during this specific range of versions, the parser utilized a max_tokens limit designed to prevent excessively large or complex queries from overwhelming system resources. The fundamental technical flaw lies in how this token counter interacts with comment handling within the Lexer.advance_lexer function. When the lexer processes an incoming GraphQL document, it employs a lookahead mechanism that skips over comments to determine if subsequent tokens are valid for parsing. While these skipped comments are correctly ignored for syntactic validity and AST generation purposes, they were still allocated as Token objects in memory. Crucially, each of these comment-based token allocations was retained within the linked list structure via next and prev pointers, even though they did not contribute to the count against the max_tokens limit because only non-comment tokens were tallied by the counter logic.
This discrepancy creates a significant attack vector for unauthenticated remote attackers seeking to perform denial-of-service attacks through memory exhaustion. By crafting GraphQL documents that are heavily padded with comments but contain very few actual executable operations or fields, an attacker can bypass the intended token limit protections. The document would appear compliant with the max_tokens threshold because the counter only increments for substantive tokens like field names and arguments. However, as the parser processes this comment-heavy payload, it allocates memory for every single comment encountered in the lookahead phase. Since these allocations persist through the linked list structure before being discarded or processed further, a sufficiently large volume of comments can rapidly consume available worker memory on the server hosting the GraphQL endpoint. This resource consumption occurs prior to the execution of higher-level security controls such as AST-based depth limiting and complexity analysis, which are typically designed to mitigate query-related attacks like deep nesting or expensive field resolution. Consequently, the system may become unresponsive or crash due to out-of-memory conditions before these secondary safeguards have any opportunity to evaluate or reject the malicious request.
The operational impact of this vulnerability is severe for services relying on GraphQL-core for handling user-generated queries. An attacker can exploit this flaw remotely without authentication by sending a series of carefully constructed requests that maximize comment density relative to token count. This leads to rapid degradation of service availability, affecting not only the targeted endpoint but potentially impacting other processes sharing the same worker memory space in multi-tenant or shared hosting environments. The lack of immediate failure upon hitting the token limit means that standard monitoring tools might not trigger alerts until significant resource depletion has already occurred, making detection and mitigation difficult during an active attack. This behavior aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-770, specifically allocation of resources without limits or throttling. From a threat intelligence perspective, this exploitation technique is consistent with ATT&CK tactic T1496, Resource Hijacking, where adversaries leverage system resources to cause denial of service rather than directly compromising data integrity or confidentiality at the initial stage.
To mitigate this vulnerability and restore secure operation, organizations must upgrade their GraphQL-core dependencies immediately to version 3.2.12 or later, including any subsequent releases such as 3.3.0rc1 and beyond where the token counting logic has been corrected to account for all allocated tokens regardless of whether they are comments. For environments that cannot patch instantly due to dependency conflicts or testing requirements, temporary mitigations should focus on implementing strict input validation at the network perimeter using Web Application Firewalls configured to detect unusually high comment-to-token ratios in GraphQL payloads. Additionally, enforcing lower max_tokens limits can provide a buffer against memory exhaustion, although this may inadvertently block legitimate large queries and thus requires careful tuning based on application-specific needs. It is also advisable to review query complexity analysis configurations to ensure that depth and cost controls are robust enough to handle edge cases where token-based protections might be bypassed by alternative means in the future. Regular auditing of third-party library versions against known vulnerability databases remains essential for maintaining a secure GraphQL infrastructure.