ash CVE-2026-82738

Exploitation requires three concurrent conditions: (1) the target application runs ash versions 3.6.3 through 3.32.1 and exposes at least one Ash.Type.UUIDv7 attribute in a resource; (2) the attacker controls a value that reaches that attribute's write path - via an API endpoint, form submission, message queue, or any other data-ingestion mechanism - without the strict_uuid7 option being set on the attribute (strict_uuid7 is opt-in and off by default); and (3) the supplied value is a syntactically well-formed but non-version-7 UUID. Applications that generate UUIDs server-side and never accept them from external callers are not exploitable. The CVSS 4.0 AT:P (Attack Requirements: Present) metric correctly captures that a specific non-default scenario - a write-exposed UUIDv7 attribute without strict_uuid7 - is required. The AV:L designation in the original vector may reflect that the vulnerability is in an application-layer library rather than a network service; however, whether exploitation is local or remote depends on how the application itself is deployed.

The real-world risk is moderate and highly context-dependent. The CVSS 4.0 score of 5.9 with vector AV:L/AC:L/AT:P/PR:N/UI:N/VA:H reflects a high availability impact scoped to the vulnerable system, conditioned on specific attack requirements (AT:P). The availability impact is severe at the record level - a poisoned row is permanently unreadable without direct database intervention - but the blast radius is bounded to individual records rather than the full service. Exploitation requires a write path to a UUIDv7 attribute without the strict_uuid7 option enforced; real exposure therefore depends entirely on whether the application accepts externally-supplied UUID values. No EPSS score is available and the vulnerability is absent from the CISA KEV catalog, indicating no confirmed active or widespread exploitation. The attack is also notably stealthy: the write succeeds silently, and only the later read failure signals a problem, complicating detection and forensic attribution. Overall this is a genuine availability risk for affected deployments rather than a theoretical one, but its impact is narrow and the fix is straightforward.

An attacker with write access to an Ash-powered API endpoint that accepts an externally-supplied UUID for a UUIDv7-typed attribute submits a syntactically valid but non-version-7 UUID (for example, a version-5 UUID such as 550e8400-e29b-51d4-a716-446655440000). Ash accepts and stores the value without error. On every subsequent read of that record, cast_stored/2 passes the stored 16-byte binary to the now-strict cast_input/2, which returns :error, silently rendering the record permanently inaccessible without direct database remediation. No public exploit code exists at time of analysis.