CVE-2026-82745: ETS and Mnesia data layers overwrite an existing record on create instead of enforcing primary-key uniqueness
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/datalayer/ets/ets.ex, lib/ash/datalayer/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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ashto a version that resolves this vulnerability.Fixed in 3.32.2 - Compensating control
If you cannot upgrade yet, do not allow untrusted users to supply the primary key (e.g., user-supplied string/integer primary key) to a create action when using the ETS or Mnesia data layers, because create can overwrite existing records with the same primary key.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using ash versions from 0.4.0 before 3.32.2 are affected when a resource uses the ETS or Mnesia data layer. SQL data layers reject duplicate primary keys and are not described as affected by this behavior.
What does an attacker need to exploit it?
The attacker must be able to invoke a create action and supply or control the primary-key value, such as through a user-provided string or integer key. They can then choose the primary key of an existing record to overwrite that record.
What is the impact of a successful overwrite?
An existing entity can be silently destroyed and replaced through the create action. This bypasses the update action and its associated policies.
What mitigation is available if upgrading cannot happen immediately?
Restrict create actions so untrusted actors cannot set primary-key values, particularly for resources backed by ETS or Mnesia. Use data-layer or application controls that prevent attacker-controlled create requests from selecting existing record keys.
How does the fixed behavior handle duplicate keys?
The fix returns an already-taken error when a create uses an existing primary key. Duplicate creates remain allowed only for keyless resources.