CVE-2026-80223: Cross-tenant subscription disclosure in AshGraphql authorizes notifications in memory without a tenant-scoped read
Incorrect Authorization vulnerability in ash-project ashgraphql allows an authenticated subscriber in one tenant to receive another tenant's records over GraphQL subscriptions.
The subscription resolver in AshGraphql.Graphql.Resolver authorizes each notification payload in memory: its fast path calls Ash.can/3 with runqueries?: false, which evaluates the read policy filter against the in-memory record via Ash.Expr.eval/2 and never issues a query. Ash applies multitenancy at query-build and data-layer-prefix time, not inside query.filter, so the evaluated policy carries no tenant condition and a tenant-B notification routed to a tenant-A subscriber is emitted whenever the policy filter is true. The single-notification clause has no tenant guard at all, and the batched clause checks only the head of the notification list, so non-head entries authorize purely in memory. A tenant-scoped read is reached only when filter evaluation fails.
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
Event History
Frequently Asked Questions
Which deployments are affected?
ash_graphql versions from 1.4.0 before 1.11.0 are affected. Exposure requires a multi-tenant deployment that uses GraphQL subscriptions.
What does an attacker need to exploit this issue?
The attacker must be an authenticated subscriber in one tenant and receive a notification for a record from another tenant. The cross-tenant record is emitted when its policy filter evaluates true in memory, without a tenant-scoped read being performed.
Are batched subscription notifications also exposed?
Yes. For batched notifications, only the first notification is checked; non-head entries are authorized purely in memory and do not receive a tenant guard.
How can I determine whether my service may already be vulnerable?
Check whether the service runs an affected ash_graphql version and has GraphQL subscriptions serving more than one tenant. Review subscription behavior where notifications from one tenant could be routed to subscribers associated with another tenant.