CVE-2026-82367: Re-entrant synchronous publish in AshGraphql subscription batcher delivers one subscriber's records to another's topic
Exposure of Data Element to Wrong Session vulnerability in ash-project ashgraphql can deliver one subscription's resolved records to a different subscriber's topic.
AshGraphql.Subscription.Batcher.dosend/5 reads the resolved batch from the process dictionary via Process.get(:batchresolved) and then unconditionally deletes it. That is sound only inside a task the library owns. On the :backpressuresync and :noproc fallbacks dosend/5 runs inline in the publishing caller's process, so if a resolver inside an outer dosend/5 triggers another synchronous Ash notification, the inner call finds the outer run's value still under :batchresolved, adopts it as its own result, and publishes it to the inner topic, a different subscription document with a different actor and tenant. It then deletes the key, so the outer run publishes nothing. The key is not namespaced by run, so records cannot be told apart. The fix saves, clears, and restores :batchresolved around each run.
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 - Compensating control
Avoid triggering synchronous Ash notifications/re-entrant publishes inside an outer AshGraphql subscription Batcher do_send/5 run (where possible), since the re-entrant inline publishing can cause the inner call to reuse the outer run's :batch_resolved batch.
Event History
Frequently Asked Questions
Who is realistically exposed to cross-subscription record delivery?
Applications using ash_graphql versions 1.4.0 through before 1.11.0 are affected when subscription publishing reaches the synchronous :backpressure_sync or :noproc fallback and a resolver causes a nested synchronous Ash notification. The nested and outer subscriptions can have different documents, actors, and tenants.
What must happen for an attacker or user to trigger the issue?
A resolver executing during an outer synchronous publish must trigger another synchronous Ash notification while the outer batch result remains in the publishing process dictionary. The inner publish then uses the outer publish's resolved records and sends them to the inner subscription topic.
Is ordinary asynchronous task-based publishing affected?
The described process-dictionary handling is sound when do_send/5 runs inside a task owned by the library. The vulnerable behavior is specifically the inline execution used by the :backpressure_sync and :noproc fallbacks.
What can be done if upgrading is not immediately possible?
Avoid application flows where subscription resolvers trigger synchronous Ash notifications, particularly when the synchronous fallback paths may be used. The fix is to save, clear, and restore :batch_resolved around each publishing run.