CVE-2026-82564 in ash_ai
Summary
by MITRE • 08/31/2026
Authorization Bypass Through User-Controlled Key vulnerability in ash-project ash_ai allows a caller of an identity-configured tool to update or destroy records it never identified, including every row in the table.
In AshAi.Tool.Execution, identity_filter/3 built the update/destroy filter directly from the raw tool arguments as [{key, Map.get(arguments, to_string(key))}] and passed it to Ash.Query.do_filter/2. A map value is parsed as a predicate expression rather than a literal, so a caller can send {"public_ref": {"not_eq": "<own-ref>"}} and, combined with Ash.Query.limit(1) and Ash.bulk_update!/Ash.bulk_destroy!, retarget the write at a record it never identified; an omitted key yields an IS NULL filter that matches an arbitrary row. The fix casts each identity value to the field type, rejecting non-scalar inputs.
This issue affects ash_ai: from 0.6.0 before 1.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified as a Bypass of Authorization Controls through User-Controlled Key represents a critical security flaw within the Ash AI framework, specifically affecting versions ranging from 0.6.0 up to but not including 1.0.0. This issue stems directly from how the identity-based filtering mechanism handles incoming arguments in the execution context of tools. In secure application design, when an operation is scoped by a specific user or entity identifier, the system must strictly validate that all data modifications are confined exclusively to resources owned or explicitly authorized for that actor. However, in this implementation, the function responsible for constructing identity filters fails to enforce strict type constraints on the input values provided via tool arguments. This oversight allows an attacker who has access to invoke these tools to manipulate the underlying database queries through carefully crafted payloads, effectively bypassing the intended authorization boundaries and gaining unauthorized read or write privileges over data belonging to other users or system-wide records.
The technical root cause lies in the implementation of the identity_filter function within AshAi.Tool.Execution. When processing arguments for updates or deletions, the code constructs a filter list by retrieving values from the raw argument map using string keys derived from expected field names. The critical failure occurs because these retrieved map values are passed directly into the query filtering logic without prior validation or type casting. In the context of Ash.Query.do_filter/2, which interprets its input arguments as predicate expressions rather than simple literal values, a complex data structure such as a nested map is parsed as a logical expression. For instance, if an attacker provides a value structured like {"not_eq": "<own-ref>"}, the query engine interprets this not as a string to be matched literally but as a condition that evaluates whether the target record's identifier does not equal the provided reference. This semantic shift transforms what should have been a restrictive filter into a permissive one, allowing the operation to proceed against records outside the intended scope.
Furthermore, the vulnerability is exacerbated by how missing keys are handled within the argument map. If an attacker omits a specific key from their input payload, the system defaults to generating an IS NULL filter for that field. In many database schemas and application logic patterns, particularly those involving soft deletes or default values, this condition can match arbitrary rows in the target table rather than restricting results to the authenticated user's records. When combined with bulk operations such as Ash.bulk_update!/2 or Ash.bulk_destroy/3, which are designed for efficiency but operate on sets of data defined by their filters, an attacker can leverage these flawed predicates to update or destroy every row in a database table. This capability effectively allows for complete data destruction or corruption across the entire dataset associated with that tool, representing a catastrophic impact on data integrity and availability.
The operational impact of this vulnerability is severe, encompassing both confidentiality breaches and significant integrity violations. An authenticated user can escalate their privileges to perform administrative-level actions without authorization. By retargeting write operations at records they do not own, the attacker can modify sensitive information belonging to other users or system configurations. More critically, the ability to execute bulk destroy operations means that an attacker can wipe entire tables of data, leading to permanent loss of business-critical information and potential service disruption for all users relying on those datasets. This aligns with CWE-284 Improper Access Control, as it involves a failure in enforcing proper access control policies due to insufficient validation of user-supplied input that influences security decisions. Additionally, the exploitation technique relates to ATT&CK T1078 Valid Accounts and potentially T1485 Data Destruction, depending on whether the attacker uses stolen credentials or exploits existing valid sessions to carry out the malicious bulk operations.
To mitigate this vulnerability, it is imperative for developers using affected versions of Ash AI to upgrade immediately to version 1.0.0 or later, where the fix explicitly casts each identity value to its corresponding field type before passing it to the query builder. This casting process ensures that complex data structures like maps are rejected if they do not conform to expected scalar types such as strings, integers, or booleans. For organizations unable to upgrade immediately due to dependency constraints, a temporary workaround involves implementing custom middleware or wrapper functions around tool execution that strictly validate and sanitize all incoming arguments before they reach the identity filter logic. This validation should enforce type checking, ensuring that only primitive values are accepted for fields intended to serve as unique identifiers or security filters. Regular code audits focusing on how user input is integrated into database query construction processes are also recommended to prevent similar injection-style authorization bypasses in other parts of the application stack.