CVE-2026-75758 in Elixir
Summary
by MITRE • 08/28/2026
Uncontrolled Recursion vulnerability in the Elixir standard library allows an attacker who controls a list passed to inspect/1, List.to_string/1, or List.to_charlist/1 to exhaust a BEAM node's memory.
Inspect.List's charlist branch in lib/elixir/lib/inspect.ex classifies a list as a charlist using List.ascii_printable?/2, which examines only the first :printable_limit (4096 by default) elements, and then calls IO.chardata_to_string/1 on the whole term. A list whose printable prefix exceeds that limit but which contains a later element that is not a code point (an atom, an out-of-range integer, or an improper tail) is therefore mis-classified, and the conversion raises ArgumentError. That conversion runs inside List.to_string/1, whose rescue clause builds its message by interpolating inspect(list), which re-enters the same branch and raises again. The nested inspection is an argument to raise, so the recursion is not in tail position and every level is retained: the process stack grows monotonically while each cycle re-walks the list, until the process is killed by max_heap_size or, by default, the node runs out of memory. List.to_charlist/1 has the same rescue shape.
Below the printable limit the inner inspect/1 sees the invalid element within its counter and renders the list in ordinary bracket form, so a single ArgumentError is raised and no recursion occurs.
This issue affects elixir: from 1.15.0-rc.0 before 1.18.5, from 1.19.0-rc.0 before 1.19.6, and from 1.20.0-rc.0 before 1.20.4.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability described constitutes a critical uncontrolled recursion flaw within the Elixir standard library, specifically affecting the string conversion functions inspect/1, List.to_string/1, and List.to_charlist/1. This issue arises from an incorrect classification logic in the Inspect.List module, which determines whether a given term should be treated as a charlist or rendered using standard bracket notation. The core technical flaw lies in how the system validates character lists by examining only the first 4096 elements via List.ascii_printable?/2 to determine printability. If this initial prefix consists entirely of printable ASCII characters, the function proceeds to convert the entire term into a string or charlist using IO.chardata_to_string/1. However, if any element beyond that limit is not a valid code point—such as an atom, an out-of-range integer, or an improper list tail—the conversion fails and raises an ArgumentError exception.
The severity of this vulnerability stems from the error handling mechanism implemented within List.to_string/1 and List.to_charlist/1. When the initial conversion attempt fails due to invalid data structures deep within the list, these functions employ a rescue clause that attempts to generate a descriptive error message by calling inspect on the original problematic term. This call to inspect re-enters the same validation logic described above. Because the outer limit check still sees only printable characters in the first 4096 positions, it again classifies the list as a charlist and attempts another full conversion, which inevitably fails with an ArgumentError once more. The rescue clause then calls inspect on the term yet again to build its own error message, creating a recursive loop where each iteration consumes stack space without tail-call optimization. This results in monotonic growth of the process stack until the BEAM virtual machine terminates the process due to exceeding max_heap_size or exhausts node memory entirely.
From an operational impact perspective, this vulnerability enables remote denial-of-service attacks against Elixir-based applications that accept untrusted input for string conversion operations. An attacker who can control a list passed to these functions can trigger infinite recursion with minimal resource expenditure on their end, leading to significant service disruption or complete node failure in production environments. This aligns with CWE-674, which describes Uncontrolled Recursion as a weakness where recursive calls are not properly bounded by termination conditions. Furthermore, the exploitation technique maps directly to MITRE ATT&CK tactic T1499, Endpoint Denial of Service, specifically under subtechniques involving resource exhaustion through application-level flaws rather than network-layer attacks. The vulnerability is particularly dangerous because it does not require complex payload crafting beyond constructing a list with a long printable prefix followed by an invalid element, making automated exploitation straightforward for adversaries targeting Elixir services such as web servers or API endpoints that process user-supplied data structures.
The affected versions of the Elixir language include releases from 1.15.0-rc.0 up to but not including 1.18.5, versions from 1.19.0-rc.0 before 1.19.6, and versions from 1.20.0-rc.0 prior to 1.20.4. Mitigation strategies primarily involve upgrading the Elixir runtime environment to a patched version where this recursion logic has been corrected. In cases where immediate patching is not feasible, developers should implement strict input validation at application boundaries before passing any user-controlled data structures to List.to_string/1 or inspect/1 functions. This includes verifying that lists do not contain improper tails and ensuring that all elements are within valid code point ranges regardless of position. Additionally, configuring BEAM node limits such as max_heap_size can provide a partial buffer against memory exhaustion, though this is merely a defensive measure rather than a fix for the underlying logical flaw in the standard library implementation.