CVE-2026-80051 in graphql-go
Summary
by MITRE • 08/25/2026
github.com/graphql-go/graphql (GraphQL for Go) through 0.8.1 does not validate that a scalar variable value matches its declared type. The built-in coerceString and coerceBool functions (scalars.go) accept input whose type does not match the declared String, ID, or Boolean scalar instead of raising the request error that the GraphQL specification mandates. In some cases (but not any typical case of JSON sent to a website), a deeply nested value leads to an unrecoverable "fatal error: stack overflow" condition.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in github.com/graphql-go/graphql versions through 0.8.1 represents a critical deviation from the GraphQL specification regarding type coercion and validation of scalar variables. In standard GraphQL implementations, when a client provides a variable value that does not match the declared type of an argument or input field, the server is mandated to return a specific request error rather than attempting implicit conversion or accepting the mismatched data. This library fails to enforce this strict typing discipline for built-in scalars such as String, ID, and Boolean. Specifically, the internal coerceString and coerceBool functions in the scalar.go module accept inputs of incorrect types without raising the required validation errors. This lack of input validation allows clients to bypass type constraints that are fundamental to the security model and data integrity guarantees provided by GraphQL APIs.
The technical flaw stems from insufficient checks within the coercion logic before processing variable values. When a request is received, the server should verify that the runtime value matches the expected schema definition for String, ID, or Boolean fields. Instead, this implementation proceeds with operations on mismatched types. While many typical JSON payloads sent to web applications may not immediately trigger catastrophic failures due to how standard parsers handle certain type mismatches, the underlying logic remains fundamentally broken. This deviation creates a security gap where attackers can potentially exploit inconsistent behavior across different parts of an application that rely on strict typing for access control or data processing decisions.
A more severe operational impact arises in scenarios involving deeply nested structures within variable values. Due to the lack of proper type validation and boundary checks, certain malformed inputs can trigger infinite recursion during internal string conversion or boolean evaluation processes. This leads to a fatal error resulting in a stack overflow condition. Such an event causes the server process to crash abruptly, leading to a denial of service for all users attempting to interact with the GraphQL endpoint. Unlike typical application-level errors that return HTTP 400 Bad Request responses, this vulnerability results in complete unavailability of the service until the affected instance is restarted or recovered by orchestration systems. This makes it particularly dangerous as an automated attack vector against availability.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write if interpreted through memory corruption lenses, though primarily it falls under CWE-697 Incorrect Comparison due to the failure to validate type equality before processing. In terms of attack patterns, this vulnerability facilitates Denial of Service via resource exhaustion (CWE-400) and can be leveraged in conjunction with other injection techniques if the application logic downstream assumes strict typing for security checks. The ATT&CK framework categorizes such behavior under T1498 Network Denial of Service or potentially T1190 Exploit Public-Facing Application, depending on whether the crash is triggered remotely by an external actor exploiting the stack overflow condition.
To mitigate this vulnerability, organizations must upgrade to a patched version of graphql-go that implements strict adherence to the GraphQL specification regarding scalar type validation. Until upgrading is possible, developers should implement custom middleware or wrapper functions around variable resolution layers to manually enforce type checking before passing values into the core execution engine. This involves explicitly verifying that input types match their schema definitions and returning appropriate error responses for mismatches rather than allowing them through. Additionally, implementing rate limiting and request size limits can help mitigate the impact of stack overflow attempts by restricting the depth or complexity of incoming queries. Monitoring server logs for fatal panic messages related to stack overflows is also recommended as an indicator of compromise attempt targeting this specific flaw.