CVE-2026-94201: Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash

Severity: high (CVSS 8.2 v4.0)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.3% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-10-05 · updated 2026-10-06
Weakness: CWE-770

Description

Ash stores :atom-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through Ash.Type.Atom. Because the type defined no coerce/2 callback, coercion fell back to the default (cast_input/2), which calls String.to_atom/1 when the attribute is configured with the unsafe_to_atom?: true constraint. Filtering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable :atom attribute declared with unsafe_to_atom?: true can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true by default. The fix adds a coerce/2 to Ash.Type.Atom that never interns atoms — a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (cast_input/2, which still honors unsafe_to_atom?) is unchanged. This issue affects ash: from 3.5.1 before 3.34.3.

Affected products

ash-project ash: from 3.5.1 before 3.34.3 — fixed in 3.34.3

How to fix

Upgrade to a fixed version: ash-project ash 3.34.3. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-94201 or the next vulnerability affects your stack