CVE-2026-82745: Ash Framework Auth Bypass Vulnerability

CVE-2026-82745 Overview

CVE-2026-82745 is an Improper Access Control vulnerability [CWE-284] in the ash-project/ash Elixir framework. When using the ETS or Mnesia data layers, a create action fails to enforce primary-key uniqueness on insert. An actor who can set the primary key on a create operation can submit a request whose key matches an existing record, silently overwriting that record's data. The overwrite bypasses the update action and its authorization policies. The issue affects ash versions from 0.4.0 before 3.32.2.

Critical Impact

Attackers with the ability to supply a primary key on create can destroy and replace another entity's record without triggering update-action policies, resulting in silent data integrity loss.

Affected Products

• ash-project/ash versions >= 0.4.0 and < 3.32.2
• Applications using the ETS data layer (lib/ash/data_layer/ets/ets.ex)
• Applications using the Mnesia data layer (lib/ash/data_layer/mnesia/mnesia.ex)

Discovery Timeline

• 2026-09-01 - CVE-2026-82745 published to NVD
• 2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-82745

Vulnerability Analysis

The ash framework provides a resource-oriented data layer abstraction over multiple storage backends. Unlike SQL data layers, whose unique primary-key constraints reject duplicate inserts at the database level, the ETS and Mnesia backends implemented create as a keyed insert that replaced any existing entry sharing the same primary key. The vulnerability [CWE-284] therefore allows a create action to perform what is effectively an unauthorized update, bypassing policies attached to the update action.

The practical impact depends on whether an actor can influence the primary-key attribute during creation. Resources that expose user-supplied string or integer keys, such as slugs, external identifiers, or client-generated UUIDs, are directly exploitable. Because the overwrite path never invokes the update action, audit logging tied to updates may also fail to record the tampering.

Root Cause

The ETS backend used ETS.Set.put/2, which unconditionally writes an entry at the given key. The Mnesia backend computed a primary key from resource attributes without checking for prior existence before insert. Neither backend distinguished between resources that declare a primary key and keyless resources, so both flows accepted duplicate keys silently.

Attack Vector

Exploitation requires local access to an interface that invokes a create action where the primary-key attribute is writable by the caller. The attacker submits a create request whose primary key matches a target record. The data layer overwrites the existing entry with attacker-controlled values, replacing the victim's data without traversing update policies.

// Security patch: lib/ash/data_layer/ets/ets.ex
// Replaces ETS.Set.put (upsert) with :ets.insert_new (insert-or-fail)
case dump_to_native(record, attributes) do
  {:ok, casted} ->
-    case ETS.Set.put(table, {pkey, casted}) do
-      {:ok, set} ->
-        {_key, record} = ETS.Set.get!(set, pkey)
-        cast_record(record, resource)
-
-      other ->
-        other
+    if :ets.insert_new(table.table, {pkey, casted}) do
+      {_key, record} = ETS.Set.get!(table, pkey)
+      cast_record(record, resource)
+    else
+      {:error, pkey_already_taken_error(resource)}
    end

  other ->
    other
end

+defp pkey_already_taken_error(resource) do
+  Ash.Error.Changes.InvalidChanges.exception(
+    fields: Ash.Resource.Info.primary_key(resource),
+    message: "has already been taken"
+  )
+end

Source: GitHub Commit 912e243

Detection Methods for CVE-2026-82745

Indicators of Compromise

• Records whose non-key attributes change without a corresponding entry in update-action audit logs.
• Create-action log entries where the supplied primary key matches a pre-existing record identifier.
• Divergence between application-level activity logs and ETS or Mnesia table state after create operations.

Detection Strategies

• Review application logs for create invocations against resources that permit client-supplied primary keys, and correlate them with existing record identifiers.
• Inspect deployed dependencies for ash versions between 0.4.0 and 3.32.2 using package manifests such as mix.lock.
• Compare snapshots of ETS and Mnesia tables over time to identify record mutations not preceded by an update action.

Monitoring Recommendations

• Alert on repeated create failures returning has already been taken after upgrade, which may indicate active exploitation attempts.
• Track authorization decisions for update actions and flag resources whose update policies are rarely triggered despite frequent data changes.
• Aggregate resource-mutation telemetry into a centralized log store for retrospective analysis of pre-patch activity.

How to Mitigate CVE-2026-82745

Immediate Actions Required

• Upgrade ash to version 3.32.2 or later in all applications using the ETS or Mnesia data layers.
• Audit resource definitions to identify any create actions that expose the primary-key attribute to user input.
• Restrict primary-key attributes to server-generated values, such as UUIDs produced during changeset construction, where feasible.

Patch Information

The fix is delivered in ash3.32.2 via commit 912e243. The ETS backend now uses :ets.insert_new/2, which fails when the key already exists and returns an InvalidChanges error with the message has already been taken. The Mnesia backend generates a synthetic reference key for keyless resources so duplicates are only permitted where no primary key is declared. See the GitHub Security Advisory GHSA-92x7-q3h5-wf88, the CNA advisory for CVE-2026-82745, and the OSV record EEF-CVE-2026-82745.

Workarounds

• Remove the primary-key attribute from the accept list of any create action to prevent client control over the key.
• Add a custom changeset validation that queries the data layer for an existing record with the supplied primary key before insert.
• Migrate sensitive resources to a SQL data layer, which enforces primary-key uniqueness at the database level.

# Upgrade ash to the patched release in mix.exs
# {:ash, "~> 3.32"} -> ensure resolved version is >= 3.32.2
mix deps.update ash
mix deps.get
mix compile --force