Vulnerability advisory
EEF-CVE-2026-54894
Atom-table exhaustion denial of service in Guardian via unbounded atom creation from binary keys
Also known as CVE-2026-54894GHSA-xqch-c77q-rgh5
- CVSS 4.0
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H
Affected versions
| Affected | Fixed in |
|---|---|
0.1.0 to before 2.4.1 | 2.4.1Advisories → |
Also listed as affected (53) | |
Repository
| Affected commits | Fixed by commit |
|---|---|
| GIT github.com/ueberauth/guardian ↗ | |
| 7126fa433afc2563fcac0c9aa35193965f8fd5f8 to before 2952657e42e6341a67e6aaad09d8f0b40ae917cb | 2952657e42e6341a67e6aaad09d8f0b40ae917cb |
Also listed as affected (32)
| |
Description
Summary
Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-influenced binary input.
Guardian.Plug.Keys derives connection and session namespace keys by passing arbitrary binaries to String.to_atom/1. base_key/1 in lib/guardian/plug/keys.ex converts any binary into the atom :"guardian_<input>", and the derived helpers claims_key/1, resource_key/1, and token_key/1 create a second atom on top of that. key_from_other/1 likewise converts a regex-captured binary through String.to_atom/1. The public specs advertise String.t() as a valid argument, so passing a string is documented usage, and higher-level entry points such as Guardian.Plug.current_token(conn, key: key) thread the caller-supplied key straight into these functions.
String.to_atom/1 creates a brand-new atom for every previously unseen binary, atoms are never garbage collected, and the BEAM atom table is fixed at roughly 1,048,576 entries by default. An application that routes attacker-influenced data (a tenant identifier, header, or other request input) into a Guardian key therefore mints one permanent atom per distinct value. A modest stream of varied, unauthenticated input permanently consumes the atom table and crashes the BEAM node, taking down every application running on it.
This issue affects guardian: from 0.1.0 before 2.4.1.
Workarounds
Do not derive Guardian keys from untrusted input. Use a fixed, hardcoded set of namespace keys, or validate the value against a bounded allowlist of known keys, before passing it as the :key option.
Configurations
Only applications that derive a Guardian key (the conn/session namespace) from attacker-influenced data are exploitable. This is the case when a caller-supplied value such as a tenant identifier, request header, or other request input is passed as the :key option to entry points like Guardian.Plug.current_token/2. Applications that use a static namespace (the default :default key or hardcoded atoms) are not affected.