CVE-2026-34593: Ash Framework DoS Vulnerability

CVE-2026-34593 Overview

A resource exhaustion vulnerability exists in the Ash Framework, a declarative, extensible framework for building Elixir applications. Prior to version 3.22.0, the Ash.Type.Module.cast_input/2 function unconditionally creates a new Erlang atom via Module.concat([value]) for any user-supplied binary string that starts with "Elixir.", before verifying whether the referenced module exists. Because Erlang atoms are never garbage-collected and the BEAM atom table has a hard default limit of approximately 1,048,576 entries, an attacker who can submit values to any resource attribute or argument of type :module can exhaust this table and crash the entire BEAM VM, taking down the application.

Critical Impact

An unauthenticated attacker can crash the entire BEAM virtual machine by exhausting the atom table, causing a complete denial of service for all applications running on the VM.

Affected Products

• Ash Framework versions prior to 3.22.0
• Elixir applications using the :module type for resource attributes or arguments
• Any BEAM-based application using vulnerable Ash Framework versions

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-34593 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34593

Vulnerability Analysis

This vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption). The root issue lies in how the Ash Framework handles module type casting without proper validation. When processing user input, the framework attempts to create atoms dynamically without first checking if the corresponding module exists.

The BEAM virtual machine (Erlang's runtime) has a fundamental architectural characteristic: atoms are interned and never garbage-collected. This design decision, while beneficial for performance in normal operations, creates a critical attack surface when atom creation can be influenced by untrusted input. The default atom table limit of approximately 1,048,576 entries becomes a hard ceiling that, once reached, causes the entire VM to crash.

The vulnerability is exploitable over the network without requiring authentication or user interaction, though some attack complexity exists due to the need to identify and target appropriate input vectors.

Root Cause

The vulnerability stems from improper input validation in the Ash.Type.Module.cast_input/2 function. The function calls Module.concat([value]) on user-supplied binary strings that begin with "Elixir." without first verifying that the module exists. This creates a new atom in the BEAM atom table for each unique string submitted, regardless of whether the module is valid. Since atoms are never garbage-collected, repeated requests with unique values will eventually exhaust the atom table.

Attack Vector

The attack can be executed remotely over the network by any attacker who can submit values to resource attributes or arguments configured with the :module type. The attacker sends HTTP requests containing unique strings prefixed with "Elixir." to endpoints that process these module-type inputs. Each unique string creates a new atom, and by sending approximately one million unique values, the attacker can exhaust the atom table and crash the entire BEAM VM.

The attack mechanism involves systematically generating unique module-like strings (e.g., "Elixir.Attacker.Module1", "Elixir.Attacker.Module2", etc.) and submitting them through vulnerable input vectors. The attack does not require any special privileges or authentication, making it particularly dangerous for publicly accessible Elixir applications.

Detection Methods for CVE-2026-34593

Indicators of Compromise

• Unusual growth in BEAM atom table utilization approaching the 1,048,576 limit
• High volume of requests containing unique "Elixir." prefixed strings in module-type parameters
• BEAM VM crashes with atom table exhaustion errors in logs
• Abnormal patterns of input values to endpoints accepting module types

Detection Strategies

• Monitor atom table usage using :erlang.system_info(:atom_count) and alert when approaching thresholds
• Implement rate limiting on endpoints that accept module-type inputs
• Log and analyze patterns of unique module names submitted to the application
• Deploy web application firewalls (WAF) to detect high-volume requests with suspicious patterns

Monitoring Recommendations

• Set up alerts for atom table usage exceeding 80% of the default limit (approximately 838,000 atoms)
• Monitor application restart frequency which may indicate successful DoS attacks
• Track unique input values per session/IP to identify potential exploitation attempts
• Implement centralized logging to correlate attack patterns across multiple application instances

How to Mitigate CVE-2026-34593

Immediate Actions Required

• Upgrade Ash Framework to version 3.22.0 or later immediately
• Audit applications to identify all uses of the :module type in resource attributes and arguments
• Implement input validation to whitelist allowed module names before processing
• Consider rate limiting on affected endpoints as a temporary measure

Patch Information

The vulnerability has been patched in Ash Framework version 3.22.0. The fix ensures proper validation before atom creation, preventing untrusted input from exhausting the atom table. Users should upgrade to this version or later as soon as possible.

For detailed patch information, refer to the GitHub Release v3.22.0 and the GitHub Security Advisory GHSA-jjf9-w5vj-r6vp.

Workarounds

• Replace :module type attributes with string types and implement manual validation against an allowlist of permitted modules
• Implement application-level input validation to reject module names not matching known valid modules
• Increase the BEAM atom table limit using the +t flag (e.g., +t 2097152) as a temporary measure, though this only delays exhaustion
• Deploy network-level rate limiting to reduce the speed at which an attacker can exhaust the atom table

# Configuration example - increase BEAM atom table limit (temporary workaround)
# Add to your VM args file (vm.args or rel/vm.args.eex)
+t 2097152

# Or set via environment variable when starting the application
ERL_FLAGS="+t 2097152" mix phx.server