CVE-2026-81636: Query-complexity limit bypass via first/last pagination arguments in AshGraphql enables denial of service
Allocation of Resources Without Limits or Throttling vulnerability in ash-project ashgraphql allows an unauthenticated client to bypass the configured GraphQL query-complexity limit and force an unbounded database read.
AshGraphql.Graphql.Resolver.querycomplexity/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 childcomplexity + 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 maxcomplexity 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 ashgraphql: from 0.16.23 before 1.11.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_graphqlto a version that resolves this vulnerability.Fixed in 1.11.0 - Configuration
Update AshGraphql so query_complexity/3 includes first and last pagination arguments and clamps them to the action's page size (this prevents bypass of the GraphQL query-complexity limit via first/last relay/keyset pagination).
AshGraphql.Graphql.Resolver.query_complexity/3 :limit pagination handling (including clamping for first/last) = clamp first and last to the action's page size
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using ash_graphql versions from 0.16.23 before 1.11.0 are affected when GraphQL query-complexity limiting is relied on to constrain database work. The bypass applies to Relay connections and keyset pagination using first or last arguments.
Does an attacker need authentication or special access?
No. An unauthenticated client can exploit the issue by submitting a nested GraphQL query with large first or last pagination values.
Why does the configured max_complexity limit not stop the request?
The vulnerable complexity calculation multiplies nested child complexity for offset pagination using limit, but treats first and last pagination requests as only child complexity plus one. As a result, a high-fan-out nested Relay or keyset query can be accepted as cheap while causing an unbounded database read.
What version resolves the issue?
Upgrade ash_graphql to version 1.11.0 or later. The fix accounts for first and last arguments and clamps them to the action's page size.
How can I assess whether requests may be exploiting this?
Review GraphQL requests for nested Relay connection or keyset pagination queries that supply unusually large first or last values, especially where query-complexity enforcement accepted them. Equivalent queries using limit may be rejected by the complexity cap while the first or last variants are accepted.