CVE-2026-81643: Broken access control in AshGraphql subscription batcher applies authorization suppression to only the first notification
Incorrect Authorization vulnerability in ash-project ashgraphql delivers GraphQL subscription payloads for records a subscriber is not authorized to see.
In AshGraphql.Subscription.Batcher, dosend/5 resolves the first notification of a batch and filters it with shouldsend?/1, which drops results whose errors are coded forbidden or notfound or carry no code, precisely so that unauthorized results are not disclosed. The remaining notifications in the batch are read from the process dictionary, re-run through the pipeline, and appended to the outgoing results without that filter. They reach pubsub.publishsubscription/2, and the not isnil(record) guard drops only nil records, not error-carrying results. Any two qualifying notifications arriving within the default one-second batch interval suffice, and batching is the default path. The fix applies shouldsend?/1 to the whole batch.
This issue affects ashgraphql: from 1.4.0 before 1.11.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_graphqlto a version that resolves this vulnerability.Fixed in 1.11.0 - Configuration
Update AshGraphql.Subscription.Batcher so that authorization suppression using should_send?/1 is applied to every notification in the subscription batch, not only the first item resolved by do_send/5.
AshGraphql.Subscription.Batcher (do_send/5 / should_send?/1) Authorization filtering in subscription batcher = Apply should_send?/1 to the whole batch (not only the first notification)
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using ash_graphql versions from 1.4.0 before 1.11.0 that deliver GraphQL subscriptions are affected. Batching is the default subscription delivery path.
What does an attacker need to trigger unauthorized subscription data delivery?
Two qualifying subscription notifications must arrive within the default one-second batch interval. The issue can expose payloads for records that the subscriber is not authorized to view.
How can teams determine whether they may already be affected?
Check whether the application runs an affected ash_graphql version and uses GraphQL subscriptions. Review subscription behavior where batches can contain multiple notifications, particularly where later notifications may produce forbidden, not_found, or uncoded error results.
What should be done if patching cannot happen immediately?
The provided data identifies batching as the vulnerable default path but does not specify a validated workaround. Prioritize updating to ash_graphql 1.11.0 or later, where should_send?/1 is applied to the entire batch.