CVE-2026-82752 in ash
Summary
by MITRE • 09/05/2026
Improper Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to store a value of arbitrary size in an attribute whose length constraint should bound it.
Ash measures string length with Elixir's String.length/1, which counts Unicode graphemes, in the max_length and min_length constraints of Ash.Type.String (apply_constraints/2 in lib/ash/type/string.ex), in Ash.Resource.Validation.StringLength, and in the string_length expression function. A grapheme carries an unbounded number of combining marks, so a base character followed by a million combining acute accents is one grapheme and megabytes of data, and satisfies max_length: 2. Where the data layer imposes no independent limit (ETS, Mnesia, or a Postgres text column) the whole value is persisted, so an attacker can write an entire request body into an attribute declared with a small maximum and grow storage without bound.
The counting unit also disagrees with the storage layer, which counts codepoints rather than graphemes, so a value accepted by the constraint can still be rejected or truncated by the column. A Postgres varchar(n) column bounds the value itself and is not exposed.
This issue affects ash: from 0.10.0 before 3.33.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified in the Ash framework represents a critical failure in input validation logic, specifically categorized under CWE-20 Improper Input Validation. This flaw arises from a fundamental mismatch between how application-level constraints measure string length and how underlying data storage systems enforce limits on character count. The core issue lies in the use of Elixir's String.length/1 function to evaluate max_length and min_length constraints within Ash.Type.String, as well as related validation modules like Ash.Resource.Validation.StringLength. This function counts Unicode graphemes rather than codepoints or bytes, which introduces a significant security gap because a single grapheme can consist of one base character combined with an arbitrary number of combining marks. Consequently, an attacker can construct input that appears to satisfy length constraints while actually containing megabytes of data, effectively bypassing the intended size restrictions designed to prevent resource exhaustion and storage overflow attacks.
From an operational perspective, this vulnerability allows for unbounded growth of stored attributes when the underlying database layer does not impose its own independent limits on column sizes. In environments utilizing ETS, Mnesia, or Postgres text columns without explicit character count constraints at the schema level, the application persists the entire inflated value despite it violating the logical intent of the length constraint. This capability enables attackers to perform denial-of-service attacks by exhausting disk space and memory resources through carefully crafted requests that appear valid according to the framework's validation rules but are technically massive in size. The attack vector is straightforward: an attacker submits a request containing a base character followed by thousands or millions of combining acute accents, which registers as a single grapheme under Elixir’s counting logic yet occupies substantial storage space. This discrepancy undermines the integrity of data models and can lead to system instability or complete unavailability depending on the volume of malicious input processed.
The technical root cause is further complicated by an inconsistency between the application layer's measurement unit and the database layer's enforcement mechanism. While Ash validates inputs based on grapheme count, many storage layers such as Postgres varchar columns enforce limits based on codepoints or bytes. This misalignment means that even if a value passes the application-level validation check due to its low grapheme count, it may still be rejected or truncated by the database driver because it exceeds the column's byte or codepoint limit. However, in cases where the data layer lacks such independent limits, the vulnerability is fully exploitable as described. This inconsistency highlights a broader class of issues related to Unicode handling and internationalization security, often referenced under CWE-176 Improper Handling of Unicode Encoding Errors when combined with other encoding flaws, though here it primarily manifests as an input validation bypass leading to resource exhaustion akin to CWE-400 Uncontrolled Resource Consumption.
To mitigate this vulnerability, developers must upgrade the Ash framework to version 3.33.0 or later, where these counting discrepancies have been addressed in subsequent releases. For systems that cannot immediately upgrade, a robust workaround involves implementing custom validation logic that counts bytes or codepoints rather than relying solely on grapheme-based string length checks for fields with strict size requirements. Additionally, database administrators should enforce explicit character limits at the schema level using varchar(n) constraints where applicable, ensuring that even if application-level validation fails to catch oversized inputs, the storage layer will reject them before persistence occurs. This defense-in-depth approach ensures that both logical and physical boundaries are respected, preventing attackers from exploiting the gap between Unicode grapheme counting and actual data size. The vulnerability is tracked in ATT&CK techniques related to Resource Hijacking and Denial of Service via application-layer exploitation, emphasizing the need for rigorous input sanitization strategies that account for complex character compositions.