CVE-2026-82745 in ash
Summary
by MITRE • 09/01/2026
Improper Access Control vulnerability in ash-project ash lets a create action overwrite an existing record when the ETS or Mnesia data layer is used, because neither enforced primary-key uniqueness on insert.
Unlike a SQL data layer, whose unique primary-key constraint rejects a duplicate, the ETS and Mnesia data layers implemented create as a keyed insert that replaces any existing entry with the same primary key (lib/ash/data_layer/ets/ets.ex, lib/ash/data_layer/mnesia/mnesia.ex). An actor who can set the primary key on a create (for example a user-supplied string or integer key) can submit a create whose key matches an existing record and silently overwrite it, destroying and replacing another entity's data without going through the update action or its policies. The fix rejects a create whose primary key already exists with an already-taken error, and only allows duplicates for keyless resources.
This issue affects ash: from 0.4.0 before 3.32.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the Ash framework represents a critical improper access control flaw within its data layer implementations, specifically affecting versions ranging from 0.4.0 up to but not including 3.32.2. This security issue stems from a fundamental design discrepancy between how relational database systems handle primary keys and how Erlang-based storage backends like ETS and Mnesia manage keyed inserts. In traditional SQL environments, the insertion of a record with an existing unique primary key triggers a constraint violation error, thereby preventing accidental or malicious overwrites. However, the Ash framework's implementation for ETS and Mnesia data layers treats create actions as direct keyed insertions that silently replace any pre-existing entry sharing the same primary key identifier. This behavior bypasses standard update mechanisms and their associated authorization policies, creating a significant gap in access control enforcement where identity verification and permission checks are circumvented by simply reusing an existing unique identifier during creation rather than updating through proper channels.
From a technical perspective, the root cause lies in the lack of enforced primary key uniqueness validation on insert operations within these specific data layers. When an actor possesses the ability to supply or manipulate the primary key value for a create action, they can intentionally select a key that corresponds to an existing record in the database. By doing so, the system executes a replacement operation rather than generating an error or routing through update logic. This allows an unauthorized user to overwrite another entity's data without triggering audit logs associated with updates or checking permissions defined for modification actions. The vulnerability is particularly dangerous because it exploits the implicit trust placed in primary key uniqueness constraints that are not actively enforced at the application layer when using ETS or Mnesia backends, leading to silent data corruption and loss of integrity.
The operational impact of this flaw is severe, as it enables unauthorized data manipulation and potential denial of service through data destruction. An attacker who can control input fields mapped to primary keys can overwrite critical records belonging to other users or system processes. This undermines the confidentiality and integrity aspects of the CIA triad, as sensitive information may be replaced with malicious content or deleted entirely under the guise of a new creation event. Furthermore, because this action bypasses update policies, it also violates audit trails that rely on tracking modification events, making forensic analysis difficult after an incident occurs. The ability to silently overwrite records without triggering standard security checks means that traditional intrusion detection systems monitoring for update anomalies may fail to detect these attacks, leaving the application vulnerable to persistent compromise and data integrity violations.
To mitigate this vulnerability, developers must upgrade the Ash framework to version 3.32.2 or later, where the fix explicitly rejects create actions with existing primary keys by returning an already-taken error code. This change ensures that any attempt to insert a duplicate key is intercepted before it can overwrite data, forcing interactions through proper update pathways if modification of existing records is intended. For applications unable to upgrade immediately, implementing custom validation logic in resource definitions to check for the existence of a primary key prior to insertion serves as an effective workaround. Additionally, enforcing unique constraints at the database level where possible and reviewing all create actions that accept user-supplied identifiers can help reduce exposure. It is also advisable to audit existing codebases for patterns where primary keys are derived from external inputs, ensuring that such values are validated against current records before being passed to data layer operations.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-697 Incorrect Comparison Error in terms of its mechanism, as it involves a failure to properly validate input against expected state constraints. In the context of the MITRE ATT&CK framework, this flaw facilitates techniques related to Data Manipulation and Defense Evasion by allowing attackers to alter data without triggering standard security monitoring for update events. The silent nature of the overwrite operation means that adversaries can maintain persistence or disrupt services while avoiding detection mechanisms designed to flag modification activities. Addressing this issue requires a holistic approach combining framework updates, input validation enhancements, and rigorous testing of access control policies across all supported data layers to ensure consistent enforcement of integrity constraints regardless of the underlying storage technology employed by the application architecture.