The Number That Should Alarm Every Elixir and Erlang Developer

The Erlang Ecosystem Foundation’s CVE Numbering Authority has published the data, and it demands attention: 35.8% of CVEs issued under the EEF CNA fall into the uncontrolled resource consumption category. No other vulnerability class comes close. That single statistic reframes atom exhaustion from an occasional embarrassment into the defining security problem of the BEAM ecosystem.

The EEF CNA now tracks this distribution publicly on its Common Weaknesses page, giving the industry concrete numbers where previously there was only anecdotal concern. Those numbers show that a disproportionate share of uncontrolled resource consumption cases trace back to one recurring root cause — atom exhaustion. Not misconfigured infrastructure. Not weak cryptography. Not injection flaws. Atoms.

The mechanism is unforgiving. Atoms in the BEAM VM are stored in a fixed global atom table and never garbage collected. Once that table fills, the VM crashes. Any code path that creates atoms from non-finite or user-supplied input is a latent denial-of-service vulnerability waiting for an attacker to find it. The obvious offenders are well-known — binary_to_atom/1, String.to_atom/1, list_to_atom/1 — but dangerous patterns extend far beyond those explicit calls, hiding in deserialization logic, dynamic module loading, and protocol parsers that developers never flagged as security-sensitive.

The community has historically treated this as a developer education problem. Warn people about the footguns, publish the best practices, trust engineers to read the documentation. That approach has failed. The CVE record proves it. When a single root cause accounts for a structurally dominant share of an ecosystem’s published vulnerabilities over time, the problem is not that individual developers keep making the same mistake. The problem is that the design environment makes the dangerous path easy and the safe path optional.

The EEF CNA’s data quantifies what the ecosystem should have treated as a crisis years earlier. Now that the numbers are public, the conversation has to shift from educating developers about atom exhaustion to asking why the platform, the tooling, and the security review culture have allowed it to generate this volume of CVEs in the first place.

What Atom Exhaustion Actually Is — And Why the ‘Footgun’ Label Gets It Wrong

Atoms in the BEAM virtual machine are stored in a single global atom table and are never garbage collected. Every atom created during a runtime session stays in that table until the node shuts down. The default limit is 1,048,576 atoms. When that ceiling is hit, the VM crashes — not gracefully degrades, not throws a catchable error. Crashes.

That architectural fact creates a direct denial-of-service vector. Any code path that converts external input into atoms without bounds checking is a loaded weapon pointed at the entire node. Functions like binary_to_atom/1, list_to_atom/1, Elixir’s String.to_atom/1, and their equivalents are the obvious offenders, but the pattern extends well beyond those explicit calls. Libraries that deserialize data, parse headers, or map keys can trigger atom creation quietly, several layers removed from where a developer might think to look.

The Erlang Ecosystem Foundation’s CNA has published CVE data that reframes how the industry should think about this. Uncontrolled resource consumption accounts for 35.8% of all CVEs the EEF CNA has published. Atom exhaustion drives a significant share of that category. These are not edge cases or theoretical risks — they are formal security advisories issued because real libraries exposed real users to remote denial-of-service attacks through this exact mechanism.

The “footgun” label is the wrong frame entirely. Calling something a footgun implies a developer made an avoidable individual mistake — reached for the wrong function, skipped a warning in the docs, failed to apply common sense. The CVE record says something different. A vulnerability that earns a formal advisory, gets a CVE identifier, and can be triggered by a remote attacker sending crafted input is not a developer error. It is an exploitable vulnerability pattern. The distinction matters because footguns get addressed through better documentation and developer education. Vulnerabilities get addressed through design changes, tooling, and systemic fixes at the ecosystem level.

When more than a third of an ecosystem’s published CVEs trace back to one repeatable, structurally-enabled failure mode, the problem is not the developers writing the code. The problem is the design that keeps enabling it.

The Missing Context: Why This Pattern Keeps Recurring Across Libraries

Atom exhaustion vulnerabilities don’t cluster in one careless library. They surface independently across the BEAM ecosystem wherever a developer reaches for a convenient conversion function — binary_to_atom/1, String.to_atom/1, List.to_atom/1 — and feeds it data that originates outside the application’s control. JSON parsers, WebSocket handlers, HTTP routers, configuration loaders: each category has produced its own CVE, filed separately, treated as its own isolated incident. The Erlang Ecosystem Foundation’s CNA data shows that uncontrolled resource consumption accounts for 35.8% of all CVEs it has published, with atom exhaustion driving a large share of that figure. That number reflects a pattern, not a collection of unrelated mistakes.

The blast radius compounds the problem. The BEAM’s atom table is a single runtime-wide resource. Every process in a node — every OTP application, every dependency, every supervision tree — shares the same fixed pool of atoms. A vulnerability buried in a third-party JSON library doesn’t just threaten the code that calls it. It threatens the entire node. A payment processor, an authentication service, a logging pipeline: all of them crash when the atom table fills. That failure mode is categorically different from a memory leak in a single process, which the BEAM’s isolation model could contain. Atom exhaustion bypasses supervision hierarchies entirely.

The way the security community has responded makes the systemic nature of the problem harder to see. Each CVE disclosure focuses on the specific library at fault — a named package, a particular version range, a recommended upgrade. That framing is accurate but incomplete. It describes the symptom without identifying the condition. Readers patch the named library, close the ticket, and move on without recognising that the same architectural pressure exists in every other library in their dependency graph that handles external data. The root cause — the combination of a non-garbage-collected global atom table and convenient unsafe conversion functions — remains present and unnamed after every individual fix. Until the industry treats this as an ecosystem-level design constraint rather than a recurring series of library bugs, the CVE count will keep climbing.

What the Ecosystem’s Own CNA Data Reveals About Vulnerability Governance

The Erlang Ecosystem Foundation operates its own CVE Numbering Authority — a distinction that sets the BEAM community apart from most language ecosystems, where vulnerability tracking gets absorbed into generic databases with no domain-specific context. Running a CNA means the EEF assigns, publishes, and categorizes vulnerabilities directly, producing a granular record of exactly what kinds of weaknesses are appearing across Erlang and Elixir libraries. That institutional ownership of the data matters because it creates accountability that a third-party database cannot replicate.

The EEF CNA publishes a breakdown of CVEs by weakness category on its Common Weaknesses page. That breakdown is not a footnote — it is auditable, public evidence of where the ecosystem’s security problems concentrate. Library maintainers, security engineers evaluating BEAM-based infrastructure, and package consumers can read the same numbers and draw conclusions grounded in evidence rather than intuition or incident memory.

Those numbers tell a specific story. Uncontrolled resource consumption accounts for 35.8% of all CVEs the EEF CNA has published. One weakness class. More than a third of the total. Within that category, atom exhaustion is the dominant mechanism: atoms are not garbage collected, they occupy a global VM-wide table, and when that table fills, the runtime crashes. The vulnerability surface is not exotic. It emerges from ordinary library code that converts untrusted input into atoms without bounds checking.

A 35.8% concentration in a single CWE category is not a distribution that reactive patching can address. When the same structural flaw surfaces across dozens of independent packages — each one patched after a researcher files a CVE — the problem is not the individual maintainer’s oversight. The problem is that the language runtime provides the dangerous primitive with no guardrails, and the ecosystem has no automated tooling that flags unsafe atom creation patterns before code ships. The data the EEF CNA has made public removes any ambiguity about this. The signal is clear; the response still needs to match it.

What Needs to Change: From Awareness to Architectural Accountability

The CVE numbers make the verdict unavoidable: documentation has failed. The Erlang Ecosystem Foundation’s CNA data shows 35.8% of published CVEs fall under uncontrolled resource consumption, with atom exhaustion driving a large share of that figure. Warnings have existed in official docs for years. Developers keep shipping the same vulnerability anyway. The problem is not ignorance — it is that the runtime design makes the unsafe path frictionless and the safe path optional.

Fixing this requires moving controls upstream, into the toolchain itself. Static analysis tools and linter rules should flag every call to binary_to_atom/1, list_to_atom/1, String.to_atom/1, and their equivalents as requiring explicit review when input originates outside a closed, finite set. Credo, the Elixir static analysis tool, is an obvious home for such a rule. Dialyzer and other BEAM-ecosystem tools should surface atom-creation patterns that touch external input as warnings by default, not documentation footnotes. Code review cannot reliably catch these patterns at scale — automated enforcement can.

At the runtime level, the VM itself should offer per-connection or per-process atom creation limits that operators can configure. A network service receiving attacker-controlled data should not share atom table budget with the rest of the node without any throttling mechanism. Sandboxing atom creation for untrusted input paths is technically feasible and would convert a crash-level failure into a manageable, catchable error.

The Erlang Ecosystem Foundation occupies a specific institutional role here. Its CNA function means it tracks exactly how often atom exhaustion appears in the vulnerability record. That visibility creates an obligation that goes beyond publishing advisories. The EEF should designate atom exhaustion as a category-level priority — coordinating across library maintainers, publishing hardened API guidance, and pushing for toolchain changes in collaboration with the Elixir and Erlang core teams. Phoenix, Ecto, and the libraries that process the most external input are the right places to start enforcing safer defaults.

Treating each new CVE as an isolated errata item for the affected library lets the underlying structural failure persist. The fix is architectural accountability — owned collectively by the ecosystem, not offloaded to individual developers reading the right paragraph of documentation.