CVE-2026-82738 in ash
Summary
by MITRE • 09/01/2026
Improper Input Validation vulnerability in ash-project ash allows an attacker to persistently deny reads of a record by storing a non-version-7 UUID in an Ash.Type.UUIDv7 attribute.
Ash.Type.UUIDv7.cast_input/2 accepts any well-formed UUID string, including non-version-7 UUIDs, and stores it as a 16-byte binary. On read, cast_stored/2 (lib/ash/type/uuid_v7.ex) routes the stored binary back through cast_input/2, which since an input-validation tightening in v3.6.3 matches only version-7 (and optionally version-4) 16-byte binaries and otherwise expects a 36-character string. A stored non-v7 16-byte binary matches neither clause and returns :error, so every later read of that record fails. An attacker able to set such an attribute poisons the row permanently. The fix decodes any 16-byte stored binary directly in cast_stored/2.
This issue affects ash: from 3.6.3 before 3.32.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified as Improper Input Validation within the Ash framework represents a critical data integrity flaw that allows for persistent denial of service against specific records in applications utilizing this library. The core issue stems from a discrepancy between how input is validated during storage and how stored data is processed upon retrieval, specifically concerning UUIDv7 attributes managed by the Ash.Type.UUIDv7 type handler. This architectural inconsistency creates an attack vector where an adversary can permanently corrupt database rows, rendering them unreadable for subsequent operations without requiring further exploitation of other vulnerabilities.
The technical mechanism relies on the behavior of two primary functions within the library: cast_input and cast_stored. The cast_input function is responsible for validating incoming data before it is persisted to storage. In versions prior to 3.6.3, this function was more permissive, accepting any well-formed UUID string regardless of its version variant. However, a tightening in version 3.6.3 introduced stricter validation that expects inputs to be either version-7 or optionally version-4 UUIDs formatted as thirty-six-character strings. Crucially, the storage layer converts valid UUIDs into sixteen-byte binary representations for efficiency and database compatibility. The flaw emerges because cast_input accepts non-version-7 UUIDs during input processing but stores them as sixteen-byte binaries without flagging them as invalid at that stage.
The persistence of this vulnerability occurs during the read operation via the cast_stored function, which is designed to convert stored binary data back into usable application objects. In affected versions from 3.6.3 up to 3.32.2, cast_stored incorrectly routes any sixteen-byte binary through cast_input for validation rather than handling it directly as a valid UUID format. Since the input has already been validated and stored by an attacker who provided a non-version-7 UUID string that was accepted due to earlier permissive logic or specific edge cases in the casting process, the resulting sixteen-byte binary does not match the strict patterns expected by cast_input for version-7 or version-4 formats when processed as raw input. Consequently, cast_stored returns an error state because it cannot reconcile the stored binary with its current validation rules.
This design flaw results in a permanent denial of service condition for any record containing such a poisoned attribute. Once an attacker successfully writes a non-version-7 UUID to an Ash.Type.UUIDv7 field, every subsequent attempt by legitimate users or system processes to read that specific record will fail due to the internal casting error. This effectively locks the data behind an unrecoverable application-level barrier unless manual database intervention is performed to correct the binary value directly in storage. The impact extends beyond simple availability loss; it compromises data integrity and can disrupt workflows dependent on reading these records, potentially causing cascading failures in higher-level business logic that assumes successful record retrieval.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to properly validate input against expected formats before storage, leading to unexpected behavior during subsequent processing. It also relates to CWE-697 Incorrect Comparison, specifically in how the stored binary data is evaluated against validation patterns designed for string inputs rather than raw byte sequences. In terms of attack tactics, this maps to ATT&CK technique T1485 Data Destruction, where an attacker intentionally corrupts or destroys data within a system to disrupt operations and compromise availability.
Mitigation strategies must prioritize upgrading the Ash framework to version 3.32.2 or later, which resolves the issue by modifying cast_stored to decode any valid sixteen-byte binary directly without re-routing it through the stricter input validation logic of cast_input. For organizations unable to immediately upgrade, manual remediation involves identifying affected records in the database and correcting the UUID values to conform strictly to version-7 standards before they are read again. Additionally, implementing strict application-level monitoring for casting errors can help detect such poisoning attempts early, allowing administrators to isolate compromised rows before widespread disruption occurs. Ensuring that all input validation layers consistently handle both string inputs and stored binary representations is essential to preventing similar logic flaws in future updates or custom implementations of the type handler.