ash_graphql CVE-2026-81643

Three conditions must hold simultaneously: (1) The attacker is an authenticated user with a valid GraphQL subscription open on ash_graphql (PR:L - unauthenticated exploitation is not possible); (2) at least two subscription notification events for records the attacker is not authorized to access must arrive within the same batch interval, which defaults to one second (AT:P - the specific timing prerequisite that prevents trivial single-event exploitation); (3) ash_graphql 1.4.0-1.10.x must be deployed with GraphQL subscriptions enabled and the Batcher running (batching is the default path). Limiting factors: read-only confidentiality impact only (no write or availability exposure); restricted to subscription-capable deployments, not standard GraphQL queries or mutations; timing dependency limits reliable exploitation to scenarios with high event rates or attacker-controlled event triggers.

The CVSS 4.0 score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L) correctly reflects a tightly constrained exploitability profile: the attacker must hold a valid authenticated subscriber session (PR:L), and two notifications for unauthorized records must coincide within the same batch window (AT:P - a specific timing prerequisite). Impact is bounded to low-level confidentiality disclosure of subscription field data only; integrity and availability are unaffected. No CISA KEV listing and no public exploit code exist, consistent with a low EPSS expectation for a niche Elixir library. The 'Authentication Bypass' tag in the input metadata is factually wrong - authentication is required per PR:L, and the root cause is authorization logic, not authentication. Real-world prioritization is low-to-medium: the product footprint is limited to Elixir applications using GraphQL subscriptions, exploitation requires both an authenticated subscription and a timing coincidence, and mass automated exploitation is implausible despite the network attack vector.

An authenticated user holds an open GraphQL subscription for a resource type they are not authorized to view. When two or more records of that type are created or updated within a one-second window - for example, a bulk-create operation or rapid sequential writes - the batcher coalesces both events, filters the first via should_send?/1, but delivers the unauthorized data from the second notification directly to the subscriber's WebSocket. The patch regression test in the commit diff confirms this sequence is reliably reproducible; no separate public proof-of-concept has been identified.