CVE-2026-81633 in ash_graphql
Summary
by MITRE • 08/30/2026
Improper Input Validation vulnerability in ash-project ash_graphql allows an unauthenticated client to crash a relay node(id: ...) query with an unhandled KeyError.
AshGraphql.Graphql.Resolver.resolve_node/2 decodes the client-supplied global ID with decode_relay_id/1, which only base64-decodes the string and splits it on : without validating the type segment. The decoded type is passed straight to Map.fetch!(type_to_domain_and_resource_map, type). Because fetch! raises on a missing key, a relay ID whose type segment is a valid atom that is not a relay-exposed type aborts the resolver before its resolve/2 clauses and their rescue handlers run, so the error never becomes a GraphQL error and may expose a stacktrace. Common resource names are easy to guess. The fix uses Map.fetch/2 and returns an Invalid node id error for unknown types.
This issue affects ash_graphql: from 0.27.0 before 1.11.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in the ash-graphql library represents a critical failure in input validation within its GraphQL resolver logic, specifically affecting versions ranging from 0.27.0 up to but not including 1.11.0. This flaw allows an unauthenticated attacker to trigger a server-side crash by exploiting how global identifiers are processed during relay node queries. The core of the issue lies in the AshGraphql.Graphql.Resolver.resolve_node/2 function, which is responsible for translating client-supplied global IDs into internal domain resources. When this function receives a request, it invokes decode_relay_id/1 to parse the identifier string. This decoding process involves base64 decoding followed by splitting the resulting string on the colon character to separate the type segment from the resource-specific portion of the ID.
The fundamental technical flaw is that the implementation fails to validate whether the extracted type segment corresponds to a known, exposed relay type before attempting to use it as a map key. The decoded type is passed directly into Map.fetch/2 raises an exception immediately upon encountering an unknown key. Because the input validation step was omitted, any client-provided type string that does not match an existing entry in this map triggers a runtime exception within the Erlang virtual machine environment hosting the Elixir application.
This improper handling of unvalidated input leads to severe operational impacts beyond simple data retrieval failure. Since the exception occurs before the resolver reaches its standard clause matches and their associated rescue handlers, the error is not caught by GraphQL's normal error propagation mechanisms. Consequently, instead of returning a structured GraphQL error response that adheres to protocol standards, the server may crash or return an unhandled stack trace directly in the HTTP response body. This behavior results in a denial of service for affected endpoints and potentially exposes sensitive internal implementation details, such as module names and line numbers, which can aid further reconnaissance by attackers. The ease with which valid but non-existent type segments can be guessed exacerbates this risk, allowing automated tools to reliably trigger these crashes against exposed relay nodes.
From a classification perspective, this vulnerability aligns closely with CWE-20 Improper Input Validation, as the application fails to verify that user-supplied data conforms to expected formats and values before processing. Additionally, it relates to CWE-754: Improper Check for Unusual or Exceptional Conditions, specifically regarding the failure to handle missing keys in a map structure gracefully. In terms of offensive security frameworks, this exploit vector is consistent with ATT&CK technique T1203 Exploitation for Client Execution, where an attacker leverages client-side input to trigger server-side execution failures, and potentially T1598 Phishing for Information Gathering if the exposed stack traces are used to gather intelligence about the underlying technology stack.
To mitigate this vulnerability, organizations must upgrade ash-graphql to version 1.11.0 or later, where the fix replaces Map.fetch!/2 with Map.fetch/2. This change ensures that missing keys result in a controlled error return rather than an unhandled exception, allowing the application to gracefully respond with an Invalid node id GraphQL error message as intended by the design. For systems unable to upgrade immediately, implementing a reverse proxy or Web Application Firewall rule to inspect and reject malformed relay IDs containing unexpected type segments can provide temporary protection. Furthermore, developers should audit other areas of their codebase for similar patterns where external input is used directly in map lookups without prior validation against an allowlist of known valid types.