ash_double_entry CVE-2026-81638

Exploitation requires three concurrent conditions: (1) the target application runs ash_double_entry 0.1.0 through 1.0.18 with AshDoubleEntry.ULID-typed fields exposed as caller-controlled string identifiers over an HTTP or API boundary; (2) application logic performs security-sensitive string equality comparisons over those raw identifier strings, such as idempotency deduplication, deny-list lookups, audit log correlation, or signature verification computed over the submitted string value; and (3) the application does not independently normalize or bounds-check ULID strings before these comparisons. Deployments that generate ULIDs server-side and use them only as opaque database primary keys - never evaluating attacker-supplied ULID strings in security-sensitive equality checks - are not practically exploitable. The CVSS 4.0 AT:P metric correctly captures that these conditions are not universally present.

Real-world risk is low. The vendor CVSS 4.0 score of 2.1 (VI:L, SI:L, all other impacts N) accurately reflects that this is a narrowly scoped integrity issue rather than a broad compromise primitive. The AT:P (attack target prerequisite present) metric correctly signals that exploitation depends on conditions not present in every deployment: the application must expose ULID-typed fields as caller-controlled string identifiers and must perform security-sensitive equality comparisons over those raw strings without prior normalization. Deployments using ULIDs purely as opaque database keys - where the server generates and stores them but never evaluates attacker-supplied strings for security decisions - are not practically at risk. No EPSS score was provided in the input data, so exploitation probability cannot be quantified numerically; the absence of a CISA KEV entry and any public exploit code aligns with the low severity assessment. The vendor's CVSS 4.0 AV:L metric appears conservative given the advisory explicitly describes an HTTP and API attack surface; this discrepancy is noted and the actual network-reachable attack path is captured in the assessed vector. Overall this is a correctness and integrity hygiene issue: even a small operator running an Ash-based accounting service in a city like boleslawiec that relies on idempotency keys for payment deduplication could see real business-logic impact, but broad internet-scale exploitation is implausible without specific conditions being met.

An attacker obtains a target record's ULID from a prior API response and constructs three alternate spellings by substituting the first character with 8, G, or R - each decoding to the same 16-byte value as the original. Submitting the alternate-spelled ULID in a subsequent operation guarded by an idempotency key causes the server to locate and mutate the correct database record while the string-equality check treats the alternate spelling as a previously unseen key, permitting the operation to execute multiple times. No public proof-of-concept code has been identified.