CVE-2026-81643 in ash_graphql
Summary
by MITRE • 08/30/2026
Incorrect Authorization vulnerability in ash-project ash_graphql delivers GraphQL subscription payloads for records a subscriber is not authorized to see.
In AshGraphql.Subscription.Batcher, do_send/5 resolves the first notification of a batch and filters it with should_send?/1, which drops results whose errors are coded forbidden or not_found or carry no code, precisely so that unauthorized results are not disclosed. The remaining notifications in the batch are read from the process dictionary, re-run through the pipeline, and appended to the outgoing results without that filter. They reach pubsub.publish_subscription/2, and the not is_nil(record) guard drops only nil records, not error-carrying results. Any two qualifying notifications arriving within the default one-second batch interval suffice, and batching is the default path. The fix applies should_send?/1 to the whole batch.
This issue affects ash_graphql: from 1.4.0 before 1.11.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/30/2026
The vulnerability identified in AshGraphql versions prior to 1.11.0 represents a critical failure in access control logic within the GraphQL subscription batching mechanism, specifically located in the Subscription.Batcher module. This flaw allows an authenticated subscriber to receive data payloads for records that they are not authorized to view, constituting a severe information disclosure risk. The core of the issue lies in how batched notifications are processed and filtered before being transmitted over PubSub channels. In normal operation, AshGraphql aggregates multiple subscription updates into batches to improve performance, but this optimization inadvertently introduced an authorization bypass due to inconsistent application of security filters across different stages of the batching pipeline.
The technical root cause stems from a discrepancy in how individual notifications versus batched results are handled during transmission. When do_send/5 resolves the first notification of a batch, it correctly applies the should_send?/1 function. This filter is designed to drop any result that carries an error code indicating forbidden access or not_found status, as well as those with no specific code, thereby preventing unauthorized data from being disclosed in the initial step. However, for the remaining notifications within the same batch, the system retrieves them directly from the process dictionary and re-runs them through the pipeline without applying this critical authorization filter. These unfiltered results are then appended to the outgoing payload sent via pubsub.publish_subscription/2.
The operational impact is exacerbated by the default behavior of the batching mechanism, which groups notifications arriving within a one-second interval. Because only the first item in each batch undergoes strict access control checks, subsequent items in that same batch bypass these safeguards entirely. The guard clause not is_nil(record) present in the publishing logic ensures that empty records are dropped, but it does not validate whether those non-nil records contain sensitive data associated with authorization errors. Consequently, if a user subscribes to multiple resources or events within this short window, they may receive unauthorized access to private records belonging to other users or restricted entities, effectively bypassing the intended role-based or resource-level permissions defined in the application schema.
This vulnerability aligns with CWE-269, Improper Privilege Management, as it involves a failure to enforce proper authorization checks on specific inputs within a batched operation. Furthermore, from an offensive security perspective such as MITRE ATT&CK, this flaw facilitates Data Exfiltration over Application Layer Protocols and can be categorized under T1530, Data from Local System, if the exposed data includes sensitive local records. The lack of consistent filtering across all items in a batch creates a predictable pattern that attackers could exploit by timing their subscription requests to maximize the number of unauthorized payloads delivered per batch interval.
To mitigate this vulnerability, it is imperative to upgrade ash_graphql to version 1.11.0 or later, where the fix ensures that should_send?/1 is applied uniformly to all notifications within a batch rather than just the first one. For organizations unable to immediately patch their systems, temporary mitigations include reducing the subscription batching interval if configurable, though this may impact performance, or implementing additional authorization checks at the application layer before subscribing to sensitive resources. Regular security audits of GraphQL schema definitions and resolver implementations are also recommended to ensure that access control logic is consistently applied across all data retrieval paths, particularly in batched operations where state management can introduce subtle inconsistencies.