CVE-2026-34593
Erlang Atom Injection in Ash Framework Causes BEAM Crash
Publication date: 2026-04-02
Last updated on: 2026-04-13
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| ash-hq | ash_framework | to 3.22.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability described in CVE-2026-34593 causes a denial-of-service (DoS) by crashing the BEAM VM through exhaustion of the Erlang atom table. This results in application downtime and unavailability.
While the CVE details a high-impact DoS affecting availability, it does not explicitly mention any direct impact on data confidentiality, integrity, or privacy controls that are typically required by standards such as GDPR or HIPAA.
However, prolonged or repeated denial-of-service incidents could indirectly affect compliance by disrupting service availability, which is a component of many regulatory frameworks. Organizations relying on the Ash Framework should consider this risk in their availability and incident response planning.
Can you explain this vulnerability to me?
CVE-2026-34593 is a high-severity vulnerability in the Ash Framework, specifically in the Ash.Type.Module.cast_input/2 function. This function unconditionally creates new Erlang atoms from user-supplied binary strings that start with "Elixir." by using Module.concat([value]) before checking if the module actually exists.
Because Erlang atoms are never garbage-collected and the BEAM VM has a fixed limit of about 1,048,576 atoms, an attacker can exploit this by submitting many unique "Elixir.*" strings. Each unique string creates a new atom, eventually exhausting the atom table.
When the atom table is exhausted, the entire BEAM VM crashes, causing a denial of service and taking down all applications running on that VM instance. This vulnerability has been fixed in Ash version 3.22.0.
How can this vulnerability impact me? :
This vulnerability can lead to a complete denial of service (DoS) by crashing the BEAM VM that runs the Ash Framework application.
An attacker can remotely and without any privileges submit numerous unique module names starting with "Elixir." which causes the creation of many new atoms, exhausting the atom table.
Once the atom table is full, the BEAM VM crashes and all applications running on it become unavailable until the VM is restarted, causing downtime and potential loss of service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual or excessive creation of Erlang atoms, especially those starting with "Elixir." in your Ash Framework application logs or metrics.
Since the vulnerability involves exhaustion of the BEAM VM atom table by repeated creation of new atoms from user-supplied input, you can look for repeated requests or inputs containing unique "Elixir.*" strings.
Commands to detect this might include:
- Checking application logs for repeated or suspicious inputs starting with "Elixir."
- Using Erlang shell commands to monitor atom table usage, for example: `erlang:system_info(atom_count).` to check the current number of atoms.
- Monitoring BEAM VM crashes or restarts which may indicate atom table exhaustion.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the Ash Framework to version 3.22.0 or later, where this vulnerability has been patched.
The patch replaces the unsafe creation of new atoms via `Module.concat([value])` with safer code that only converts to existing atoms or validates atom existence before creation.
Until the upgrade can be applied, consider implementing input validation to reject or sanitize any user-supplied strings starting with "Elixir." that could lead to atom creation.
Additionally, monitor the system for signs of atom table exhaustion and be prepared to restart the BEAM VM if it crashes due to this issue.