Ash Framework's cast_input/2 creates an Erlang atom from any user-supplied binary that starts with "Elixir." by calling Module.concat without first checking if the module exists. Since Erlang atoms are immutable and not garbage collected, each call consumes an entry in the BEAM atom table, which is hard‑wired to about one million entries. The unchecked atom creation therefore constitutes both input validation and resource exhaustion weaknesses (CWE‑400 and CWE‑770). If an attacker can supply such values to a field of type :module—e.g., through an API, form or other external input—they can force the atom table to overflow, causing the BEAM Virtual Machine to crash and the entire application to become unavailable, effectively a denial‑of‑service attack.

All installations of the Ash Framework released before version 3.22.0 are affected. The issue impacts any instance where module‑typed attributes or arguments are exposed to untrusted input, including API endpoints, user‑supplied configurations, or external data sources. Users of the popular ash‑project:ash package should review whether their applications accept :module values from outside the system. Only the 3.22.0 revision or later includes the mitigation that validates the module before atom creation.

The vulnerability has a CVSS base score of 8.2, indicating high severity. Its EPSS score is lower than 1%, suggesting that exploitation is not common yet, and it is not listed in the CISA KEV catalog. Exploitation requires only the ability to submit arbitrary binary strings to a :module parameter, a capability that many web or API services provide. No privileged permissions are needed, and no complex setup is required; the attack simply drives the atom table until it overflows, leading to an immediate crash of the virtual machine. Because the BEAM atom table is a process‑global resource, the impact is system‑wide rather than confined to a single request or user.