Atom Exhaustion Is Not a Footgun. It's One Third of Our CVEs

Erlang Ecosystem Foundation - Supporting the BEAM community

Atom Exhaustion Is Not a Footgun. It's One Third of Our CVEs.

May 26, 2026 by Jonatan Männchen

Posted in Security

Tags

security

atom-exhaustion

vulnerability

dos

35.8% of CVEs published by the Erlang Ecosystem Foundation CNA fall into the category of uncontrolled resource consumption. In the BEAM ecosystem, a large share of those are caused by one recurring issue: atom exhaustion. You can find the current distribution on the EEF CNA’s Common Weaknesses page.

Atom exhaustion is a denial-of-service vulnerability. Atoms are not garbage collected and are stored in a global atom table, and once it fills up, the VM crashes. Creating atoms from non-finite values, especially user-supplied input, is therefore a latent DoS waiting to happen.

This is not limited to obvious calls such as binary_to_atom/1, list_to_atom/1, String.to_atom/1, or List.to_atom/1. Some dangerous patterns are less obvious:

% Erlang: dynamic atom creation through interpolation list_to_atom("field_" ++ UserInput) # Elixir: decoding JSON with atom keys Jason.decode(json, keys: :atoms) # Elixir: dynamic atom creation through interpolation :"field_#{user_input}"

What makes this class of vulnerability persistent is not carelessness. It often appears in code where the input was assumed to be controlled or finite. URI schemes are a good example: it may feel like there are only a few schemes to handle, but if the value comes from external input, the set is no longer guaranteed to be finite.

Creating atoms from input is unsafe unless the set of possible values is finite, known, and enforced.

The safest approach is to avoid creating new atoms at runtime entirely. Prefer explicit lookup tables when the accepted values are known:

% Erlang case Scheme of > -> http; > -> https; _ -> error end

When a lookup table is not practical, use the safer existing-atom variants, which will raise an error instead of creating a new atom:

% Erlang binary_to_existing_atom(Value) list_to_existing_atom(Value) # Elixir String.to_existing_atom(value) List.to_existing_atom(value)

Linters can help catch these patterns before they become vulnerabilities. For Elixir projects, consider enabling Credo’s Credo.Check.Warning.UnsafeToAtom, which flags unsafe calls to String.to_atom/1, List.to_atom/1, Module.concat/1,2, and Jason.decode/2 with keys: :atoms. The check is disabled by default.

If you maintain an Erlang or Elixir project, search your codebase for atom creation from binaries, strings, JSON keys, URI components, headers, and configuration values. This is one of the easiest vulnerability classes to fix before it becomes a CVE.

For more detailed guidance, see the EEF Security Working Group’s guide on preventing atom exhaustion.

Atom Exhaustion Is Not a Footgun. It's One Third of Our CVEs

Related Articles

Amazon, Facebook, FBI have access to a private intelligence-sharing network

Show HN: GoPeek – open links in live mini browser windows without new tabs

Agent Memory: An Anatomy

SpaceX not the behemoth everyone thought

The Mirror Is Part of the Machine