CVE-2026-82741 in ash
Summary
by MITRE • 09/01/2026
Improper Validation of Specified Type of Input vulnerability in ash-project ash lets an attacker confuse the stored type tag of an Ash.Type.Union value that uses storage: :map_with_tag, bypassing that member's validation and any tag-based authorization.
For a union with storage: :map_with_tag, each member is identified in storage by a configured tag and tag_value. Ash.Type.Union.dump_to_native/2 (lib/ash/type/union.ex) did not force the configured tag when writing the value, so a tag carried in the submitted value was persisted verbatim. An attacker can therefore store a value whose data belongs to one member but whose tag names a different member. On read the value is re-selected by its tag and treated as the incompatible member (a type confusion), bypassing the real member's constraints and any logic or policy that branches on the union tag. The fix drops any incoming tag and forces the configured tag value on dump.
This issue affects ash: from 2.14.18 before 3.32.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the Ash framework, specifically within versions ranging from 2.14.18 to just prior to 3.32.2, represents a critical flaw in how type unions are serialized and persisted when utilizing the map_with_tag storage strategy. This issue stems from an improper validation of specified input types during the data serialization process. In this context, Ash.Type.Union is designed to manage values that can belong to one of several distinct member types, each identified by a specific tag and associated value in the underlying database or storage mechanism. The core technical flaw lies within the dump_to_native/2 function located in lib/ash/type/union.ex. When persisting data, this function failed to enforce the configured tag for the target member type. Instead of overriding any incoming tag with the correct, pre-configured identifier associated with the actual data structure being stored, it persisted the tag exactly as provided by the input payload verbatim. This lack of strict enforcement allows an attacker to decouple the logical type from its physical representation in storage.
From a technical perspective, this behavior creates a classic type confusion scenario. When a user submits a value intended for one member of the union but includes metadata indicating it belongs to another member, the system accepts and stores this mismatched state without raising an error or correcting the tag. Consequently, when the data is later retrieved from storage, the application logic relies on the stored tag to determine how to interpret and validate the underlying data structure. Because the attacker has successfully injected a false tag pointing to a different union member, the system attempts to deserialize and process the data using the validation rules and constraints of that incorrect member type. This bypasses the actual security controls and input sanitization logic associated with the true nature of the data being stored. The discrepancy between the logical intent of the application and its physical state in the database undermines the integrity guarantees provided by the framework's type system.
The operational impact of this vulnerability is significant, particularly regarding authorization and access control mechanisms that rely on union tags for policy enforcement. Many applications use these tag-based distinctions to determine which business rules or permission checks apply to a given record. By manipulating the stored tag, an attacker can effectively trick the application into applying weaker validation constraints or bypassing critical security policies intended for the actual data type. For instance, if one member of the union represents a high-privilege role and another represents a low-privilege user, storing a high-privilege payload with a low-privilege tag could allow an attacker to persist sensitive data that would otherwise be rejected or sanitized by stricter validation rules. Conversely, it might also lead to denial-of-service conditions if the application attempts to process incompatible data structures based on the false tag, resulting in runtime errors or unexpected behavior. This flaw fundamentally breaks the assumption of trust between the application logic and its persistent storage layer regarding type integrity.
This vulnerability aligns with CWE-20 Improper Input Validation, as it involves a failure to correctly validate that the input metadata matches the expected schema constraints before persistence. Furthermore, because this issue can be leveraged to bypass authorization checks by manipulating how data is interpreted during retrieval, it also relates to CWE-862 Missing Authorization and potentially CWE-94 Improper Control of Generation of Code Command Injection if the misinterpreted types lead to unsafe code execution paths depending on the specific application implementation. In terms of adversary tactics, this technique resembles aspects of ATT&CK T1553 Subvert Trust Controls, where an attacker manipulates system mechanisms to evade detection or control, specifically by corrupting metadata used for access decisions. It also touches upon data integrity violations central to many injection-based attacks where the structure of input is manipulated to alter program flow.
The recommended mitigation involves upgrading the Ash framework to version 3.32.2 or later, which addresses this flaw by modifying the dump_to_native/2 function to explicitly drop any incoming tag and force the correct configured tag value during serialization. This ensures that the stored representation always accurately reflects the actual type of data being persisted, regardless of what metadata was included in the original request. For organizations unable to immediately upgrade, a temporary workaround involves implementing custom validation layers or middleware that strictly enforce expected tags for union types before they reach the persistence layer, ensuring that any deviation from the configured schema results in immediate rejection rather than silent acceptance and storage. Regular security audits focusing on type handling and serialization logic are also advised to detect similar patterns of improper input validation across other components of the application stack.