CVE-2026-77856 in ash_typescript
Summary
by MITRE • 09/01/2026
Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_typescript allows an unauthenticated attacker to exhaust the BEAM atom table and abort the node via client-supplied typed struct field names.
resolve_typed_struct_field/2 in lib/ash_typescript/rpc/field_processing/field_selector.ex looks a client-supplied field name up in the typed struct's reverse map and, when it finds no match, falls back to String.to_atom/1. Because this runs before any field-existence check, an unresolvable name mints a permanent atom rather than being rejected as unknown. Atoms are never garbage collected, so a request carrying many distinct names on a typed struct field grows the atom table until the VM aborts at its limit.
This issue affects ash_typescript: from 0.11.0 before 0.18.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the ash-typescript library represents a critical resource exhaustion flaw rooted in improper handling of dynamic input within the Erlang Virtual Machine environment. Specifically, this issue is classified under CWE-770 as an Allocation of Resources Without Limits or Throttling. The core technical failure occurs during the processing of client-supplied data for typed struct fields, where the application fails to validate inputs against a predefined schema before performing irreversible operations on the runtime system. This lack of input validation allows unauthenticated attackers to trigger excessive resource consumption by exploiting the specific behavior of atom creation in Erlang and Elixir systems.
The technical mechanism involves the resolve_typed_struct_field/2 function located within lib/ash_typescript/rpc/field_processing/field_selector.ex. When a client submits a request containing field names for typed structs, this function attempts to map the provided name to an existing entry in the struct's reverse map. If no match is found, rather than rejecting the input as invalid or unknown, the code falls back to calling String.to_atom/1 on the unvalidated string. In Erlang and Elixir, atoms are used extensively for identifiers such as function names, module names, and variable names. A fundamental characteristic of this language runtime is that atoms are never garbage collected; once an atom is created, it remains in memory until the node itself terminates. Consequently, every unique client-supplied string that fails to match a known field name results in the permanent allocation of a new atom in the global atom table.
The operational impact of this vulnerability is severe and directly leads to service denial. An attacker can exploit this by sending a high volume of requests with distinct, non-existent field names. Each request causes the BEAM virtual machine to allocate additional atoms without any throttling or limit checks. As the number of unique strings grows, the atom table expands until it reaches its configured maximum size. Once this threshold is exceeded, the Erlang runtime system aborts the node entirely to prevent further memory corruption or instability. This results in a complete denial of service for all users relying on that specific application instance, as the server process crashes and requires manual restart or automatic recovery mechanisms which may not be immediately available depending on deployment configuration.
This vulnerability aligns with ATT&CK technique T1498 Network Denial of Service, specifically reflecting indirect resource exhaustion through protocol abuse. The attack vector is remote and unauthenticated, making it particularly dangerous in production environments where external traffic is accepted without sufficient pre-processing validation. The flaw persists across versions from ash-typescript 0.11.0 up to but not including version 0.18.0, indicating a systemic design oversight in how dynamic field names were handled during RPC processing for TypeScript-compatible APIs built on Elixir.
Mitigation strategies must focus on preventing the creation of unbounded atoms and enforcing strict input validation before any runtime operations occur. The primary remediation is to upgrade to ash-typescript version 0.18.0 or later, where this logic has been corrected to reject unknown fields without invoking String.to_atom/1 on arbitrary user input. For systems that cannot immediately update, a temporary workaround involves implementing a custom validation layer that checks field names against an allowlist of known valid identifiers before they reach the RPC processing pipeline. Additionally, administrators should monitor atom table usage and configure BEAM limits appropriately to provide some buffer against accidental exhaustion, although this is not a substitute for fixing the underlying code flaw. Ensuring that all dynamic inputs are validated against static schemas or allowed lists is essential to maintaining system stability in Elixir-based applications exposed to untrusted networks.