CVE-2026-81636 in ash_graphql
Summary
by MITRE • 08/30/2026
Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_graphql allows an unauthenticated client to bypass the configured GraphQL query-complexity limit and force an unbounded database read.
AshGraphql.Graphql.Resolver.query_complexity/3 multiplies child complexity by the requested page size only when the argument map contains :limit (offset pagination). Relay connections and keyset pagination use first and last, which never match that clause and fall through to the catch-all that returns child_complexity + 1. A nested relay query such as posts(first: 500) { edges { node { comments(first: 500) { ... } } } } therefore scores as trivially cheap while materializing the full fan-out, passing an Absinthe max_complexity cap that rejects the equivalent limit-based query. The fix adds first and last clauses clamped to the action's page size.
This issue affects ash_graphql: from 0.16.23 before 1.11.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in ash_graphql represents a critical failure in resource management, specifically categorized under CWE-770 as Allocation of Resources Without Limits or Throttling. This flaw allows an unauthenticated client to bypass configured GraphQL query-complexity limits, leading to the potential for denial-of-service attacks through excessive database load and computational exhaustion. The core issue stems from a logic error in the AshGraphql.Graphql.Resolver.query_complexity/3 function, which is responsible for calculating the cost of incoming GraphQL queries against a predefined complexity cap designed to protect system stability.
The technical root cause lies in how pagination arguments are handled during complexity calculation. The original implementation only applied multiplication factors for child complexity when the argument map explicitly contained :limit, which corresponds to offset-based pagination strategies. However, modern GraphQL APIs often utilize Relay connections or keyset pagination, which rely on first and last arguments rather than limit and offset. Because these alternative pagination methods do not match the expected :limit clause in the conditional logic, they fall through to a default catch-all case that assigns a trivially low complexity score of child_complexity + 1 regardless of the actual data volume requested.
This discrepancy creates a significant security gap where attackers can construct nested queries that appear cheap according to the complexity analyzer but result in massive database fan-outs upon execution. For instance, a query requesting posts with first:500 and subsequently fetching comments for each post using comments(first:500) would be evaluated as having minimal complexity due to the missing limit argument check. Consequently, this request passes through the Absinthe max_complexity cap that would have correctly rejected an equivalent offset-based query. The result is a denial-of-service condition where the server attempts to materialize and return thousands of database rows in a single response, potentially exhausting memory, CPU resources, or database connection pools.
From an operational perspective, this vulnerability enables remote attackers to degrade service availability without requiring authentication. By exploiting the mismatch between pagination argument handling and complexity scoring, adversaries can force unbounded reads against backend databases. This aligns with ATT&CK technique T1496 Resource Hijacking, where resources are consumed for disruptive purposes rather than malicious data exfiltration or system compromise. The impact is primarily availability-related, as the server may become unresponsive to legitimate users due to resource saturation caused by these optimized denial-of-service payloads.
The remediation strategy involves updating the complexity calculation logic to explicitly handle first and last arguments in addition to limit. By clamping these pagination parameters to the action's configured page size during complexity assessment, the system ensures that all forms of paginated queries are evaluated accurately against resource constraints. This fix prevents the bypass of security controls by ensuring that keyset and Relay-style pagination incur appropriate computational costs proportional to their potential data output. Organizations using ash_graphql versions from 0.16.23 up to but not including 1.11.0 must apply this update immediately to restore effective protection against resource exhaustion attacks via GraphQL complexity bypasses.