CVE-2026-81638: CWE-173 Improper Handling of Alternate Encoding in ash-project ash_double_entry

The vulnerability arises because ash_double_entry's ULID rendering encodes a 128-bit ULID as 26 Crockford base-32 characters, but the first character encodes only 3 bits, limiting canonical values to 0-7. The decode function masks the first character to its low 3 bits, while the validation function accepts all 32 characters in that position. Consequently, different strings such as those starting with '0', '8', 'G', or 'R' decode to the same 16-byte ULID value, resolving to the same database row. This allows an attacker to submit differently spelled IDs that map to the same record, potentially bypassing string-level security checks when these IDs are used as public identifiers in HTTP or API contexts.

An attacker can exploit this encoding ambiguity to bypass controls relying on exact string matching of ULID identifiers. This includes evading idempotency and deduplication mechanisms, deny-lists, audit correlation, and signature verification tied to the submitted ID string. However, the underlying data record is not duplicated or corrupted; the issue is with inconsistent string representations leading to logic bypasses. The CVSS 4.0 score is 2.1, indicating low severity with limited impact and requiring local attack vector with partial impact on integrity.

No official patch or fix information is provided in the vendor advisory or source data. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users should consider implementing additional validation to enforce canonical ULID string formats and avoid accepting alternate encodings that decode to the same value. Monitoring for anomalous ID usage patterns may help detect exploitation attempts.