EEF-CVE-2026-82752

Ash string length constraints count graphemes, so a combining-mark string of any size passes max_length

## Summary 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. ## Configurations A resource attribute must carry a `max_length` constraint (or an equivalent `string_length` validation) fed from client input, and the data layer must impose no independent size limit of its own. The ETS and Mnesia data layers and Postgres `text` columns store the value in full; a Postgres `varchar(n)` column bounds it independently and is not exposed.