ash_graphql CVE-2026-82367

Two simultaneous conditions are required for exploitation. First, the AshGraphql.Subscription.Batcher process must be unavailable or under sufficient backpressure to trigger the :backpressure_sync or :noproc fallback path, causing do_send/5 to run inline in the publishing caller's process rather than in an isolated library-owned OTP task - under normal healthy Batcher operation this path is never taken. Second, a subscription resolver executing within that inline call must trigger another synchronous Ash notification, causing a re-entrant do_send/5 call within the same process that encounters the outer run's still-present :batch_resolved key. Authentication is required (PR:L per the CVSS 4.0 vector): the attacker must hold a valid, active subscription. The vulnerability is version-scoped to 1.4.0-1.10.x; deployments already on 1.11.0 or later are not affected. Single-tenant applications where cross-session leakage has no meaningful security consequence are at reduced practical risk.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N) scores 2.3, which accurately reflects the narrow exploitation window: AC:H and AT:P together capture that two independent conditions must coincide - the Batcher must be on a fallback path AND a re-entrant synchronous notification must fire during the publish cycle. The confidentiality impact is real but bounded (VC:L): resolved records from one subscription topic are delivered verbatim to a different subscriber, which in multi-tenant deployments could expose records across tenant or actor isolation boundaries - a meaningful privacy breach despite the low numeric score. No EPSS data was provided in the input, and this CVE is absent from the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The practical risk is highest for multi-tenant applications using ash_graphql 1.4.0-1.10.x where the Batcher process may be intermittently unavailable under load, enabling the fallback path. Single-tenant or non-nested-notification deployments are unlikely to encounter the race condition in practice.

A legitimate subscriber in a multi-tenant ash_graphql application sends a mutation that triggers a chained synchronous Ash notification while the Batcher is under backpressure, causing do_send/5 to execute inline in the caller's process. The inner publication run finds the outer run's :batch_resolved value - containing a different subscriber's records, potentially from a different tenant - and publishes it to the inner subscription topic, so the attacker's subscription receives data they are not authorized to see. No public proof-of-concept exploit code has been identified at time of analysis.