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

Q: Which deployments are exposed to unbounded storage growth?

Deployments that rely on Ash string max_length or min_length constraints while using a data layer without an independent value-size limit are exposed. The affected examples are ETS, Mnesia, and PostgreSQL text columns; PostgreSQL varchar(n) independently bounds the stored value and is not exposed.

Q: What does an attacker need to exploit this?

An attacker needs a path to submit a value for an attribute protected by the affected Ash string-length constraints. They can use a base character followed by arbitrarily many combining marks, which Ash counts as a single grapheme despite the value consuming substantial storage.

Q: How can teams reduce exposure if they cannot immediately update Ash?

Enforce an independent storage-size limit rather than relying solely on Ash grapheme-based length constraints. For PostgreSQL, a varchar(n) column bounds the value itself; text columns do not provide that protection.

Q: Can the issue cause validation and database behavior to differ?

Yes. Ash counts graphemes, while the storage layer counts codepoints, so a value accepted by Ash can still be rejected or truncated by the database column.

Published Sep 5, 2026

Updated

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 maxlength and minlength constraints of Ash.Type.String (applyconstraints/2 in lib/ash/type/string.ex), in Ash.Resource.Validation.StringLength, and in the stringlength 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 maxlength: 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.

Affected Software

1 affected component

ash-project ash>0.10.0<3.33.0

Event History

Sep 5, 2026

CVE Published

via MITRE·05:16 PM

Data Sourced

via MITRE·05:16 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed to unbounded storage growth?

Deployments that rely on Ash string max_length or min_length constraints while using a data layer without an independent value-size limit are exposed. The affected examples are ETS, Mnesia, and PostgreSQL text columns; PostgreSQL varchar(n) independently bounds the stored value and is not exposed.

What does an attacker need to exploit this?

An attacker needs a path to submit a value for an attribute protected by the affected Ash string-length constraints. They can use a base character followed by arbitrarily many combining marks, which Ash counts as a single grapheme despite the value consuming substantial storage.

How can teams reduce exposure if they cannot immediately update Ash?

Enforce an independent storage-size limit rather than relying solely on Ash grapheme-based length constraints. For PostgreSQL, a varchar(n) column bounds the value itself; text columns do not provide that protection.

Can the issue cause validation and database behavior to differ?

Yes. Ash counts graphemes, while the storage layer counts codepoints, so a value accepted by Ash can still be rejected or truncated by the database column.

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

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed to unbounded storage growth?

What does an attacker need to exploit this?

How can teams reduce exposure if they cannot immediately update Ash?

Can the issue cause validation and database behavior to differ?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to unbounded storage growth?

What does an attacker need to exploit this?

How can teams reduce exposure if they cannot immediately update Ash?

Can the issue cause validation and database behavior to differ?