CVE-2026-82738: Ash Framework UUID Validation DOS Vulnerability

CVE-2026-82738 is a denial of service vulnerability in ash-project ash framework caused by improper UUID validation. Attackers can permanently poison records by storing non-version-7 UUIDs. This article covers technical details, affected versions from 3.6.3 to before 3.32.2, impact analysis, and mitigation strategies.

CVE-2026-82738 Overview

CVE-2026-82738 is an improper input validation vulnerability [CWE-20] in the ash-project/ash Elixir framework. The flaw resides in Ash.Type.UUIDv7.cast_input/2, which accepts any well-formed UUID string at write time but rejects non-version-7 UUIDs on read. An attacker who can write to an Ash.Type.UUIDv7 attribute can persist a non-v7 UUID, causing every subsequent read of that record to return :error. The result is a persistent denial of read access to the affected row. The vulnerability affects ash versions from 3.6.3 before 3.32.2.

Critical Impact
An attacker with write access to a UUIDv7 attribute can permanently poison a database row, denying all future reads until the stored value is manually corrected.

Affected Products

ash-project/ash Elixir framework, versions 3.6.3 through 3.32.1
Applications using Ash.Type.UUIDv7 attributes that accept externally supplied UUID values
Downstream Elixir/Phoenix projects depending on vulnerable ash releases

Discovery Timeline

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

Technical Details for CVE-2026-82738

Vulnerability Analysis

The vulnerability stems from asymmetric validation between the write and read paths of the Ash.Type.UUIDv7 type. On write, cast_input/2 accepts any well-formed UUID string, including versions 1, 3, 4, or 5, and stores it as a 16-byte binary. On read, cast_stored/2 in lib/ash/type/uuid_v7.ex routes the stored binary back through cast_input/2. Since the input-validation tightening in version 3.6.3, cast_input/2 matches only version-7 (and optionally version-4) 16-byte binaries. A stored non-v7 16-byte binary matches neither clause and returns :error, causing every later read of that record to fail.

Root Cause

The root cause is inconsistent type enforcement across serialization boundaries. The write path is permissive, while the read path is strict. This mismatch allows non-conforming data to enter storage but blocks it from leaving. Once stored, the poisoned row cannot be retrieved through normal Ash queries.

Attack Vector

Exploitation requires an attacker to control input into an Ash.Type.UUIDv7 attribute during a create or update action. Any well-formed non-v7 UUID (for example, a UUIDv4 or UUIDv1) suffices. After the write commits, the row becomes unreadable through the Ash layer. The impact is limited to availability of the specific record.

text

       type: :boolean,
       default: false,
       doc: """
-      Requires the value to actually be a version 7 UUID. Recommended for externally-supplied values: without it, any well-formed UUID passes input casting, but non-v7 values cannot be loaded back from storage.
+      Requires the value to actually be a version 7 UUID. Recommended for externally-supplied values: without it, any well-formed UUID (not only version 7) passes input casting and is stored and loaded back as-is, so a caller can persist a non-v7 UUID in a field meant to hold v7 UUIDs.
       """
     ]
   ]

Source: GitHub Ash Commit c453cdc. The patch modifies cast_stored/2 to decode any 16-byte stored binary directly, bypassing the strict version check on the read path.

Detection Methods for CVE-2026-82738

Indicators of Compromise

Application logs showing :error returns from Ash.Type.UUIDv7.cast_stored/2 when loading specific records
Records that consistently fail to load through Ash queries while remaining present in the underlying database
User-facing error patterns tied to a specific set of primary keys or foreign keys typed as UUIDv7

Detection Strategies

Query the database directly for rows where UUIDv7-typed columns contain UUIDs whose version nibble is not 7
Correlate application error telemetry with Ash read failures on UUIDv7 attributes
Audit code paths that accept externally supplied UUIDs and cast them into Ash.Type.UUIDv7 attributes

Monitoring Recommendations

Instrument Ash read operations to alert on repeated cast_stored/2 failures per record identifier
Track write operations to UUIDv7 attributes and flag values whose version bits are not 0b0111
Review the GitHub Security Advisory GHSA-7xfw-9jwm-9c4c and OSV Vulnerability Report EEF-CVE-2026-82738 for additional context

How to Mitigate CVE-2026-82738

Immediate Actions Required

Upgrade ash to version 3.32.2 or later across all dependent applications
Enumerate schemas using Ash.Type.UUIDv7 and identify attributes populated from untrusted input
Scan storage for existing non-v7 UUID values in UUIDv7-typed columns and remediate poisoned rows
Restrict write permissions on UUIDv7 attributes so callers cannot supply arbitrary UUID values

Patch Information

The fix is delivered in ash version 3.32.2 via commit c453cdc0b8570e86ffef0d10e136247f52b3ea76. The patch updates cast_stored/2 in lib/ash/type/uuid_v7.ex to decode any 16-byte stored binary directly, so previously poisoned rows become readable again after the upgrade. Full details are available in the CNA advisory for CVE-2026-82738.

Workarounds

Enable the strict version-7 option on Ash.Type.UUIDv7 attributes that accept external input, rejecting non-v7 UUIDs at write time
Generate UUIDv7 values server-side rather than accepting them from clients
Add application-layer validation that rejects UUIDs whose version nibble is not 7 before invoking Ash create or update actions

bash

# Update the ash dependency in mix.exs, then fetch the patched release
# mix.exs
#   {:ash, "~> 3.32.2"}
mix deps.update ash
mix deps.get
mix compile