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.

Timeline

1. Sep 5, 2026, 5:16 PM UTCCVE published
2. Sep 8, 2026, 6:19 PM UTCCISA SSVC assessment

   Exploitation: poc · Automatable: no · Technical impact: partial

3. Sep 8, 2026, 6:20 PM UTCRecord last updated

Affected versions

• ash

  From 0.10.0 · fixed in 3.33.0

• ash-project/ash

  Version range not reported

References 5