Am I affected?
Description
Incorrect Authorization vulnerability in ash-project ash_graphql 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 run_queries?: 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 ash_graphql: from 1.4.0 before 1.11.0.
Weaknesses & attack patterns
Weakness
CWE-863
·
Incorrect Authorization
in catalog →
MITRE ↗
Attack patterns
CAPEC-1
·
Accessing Functionality Not Properly Constrained by ACLs
MITRE ↗
Affected — Hex / ash_graphql Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / ash-project/ash_graphql Repository ↗
modules · source files · routines
Configurations
The application exposes ash_graphql subscriptions on a multitenant resource whose read policy passes on in-memory filter evaluation alone, and where a notification created in one tenant can reach a subscriber scoped to another tenant.
References
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N