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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| ueberauth | guardian | unaffected |
|
||||||
| ueberauth | guardian | unaffected |
|
No data.
No data.
No data available yet.
Vendor Workaround
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.
Tracking
Sign in to view the affected projects.
No advisories yet.
Sat, 01 Aug 2026 19:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Atom-table exhaustion denial of service in Guardian via unbounded atom creation from binary keys | |
| First Time appeared |
Ueberauth
Ueberauth guardian |
|
| Weaknesses | CWE-770 | |
| CPEs | cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Ueberauth
Ueberauth guardian |
|
| References |
| |
| Metrics |
cvssV4_0
|
MITRE
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-01T18:46:05.861Z
Reserved: 2026-06-16T10:47:13.915Z
Link: CVE-2026-54894
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
No data.