CVE-2026-54894 in Guardian
Summary
by MITRE • 08/01/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability described represents a critical resource allocation flaw in the ueberauth guardian library that enables denial of service through unbounded atom creation. This issue stems from the improper handling of attacker-influenced binary input within the key derivation functions of the Guardian.Plug.Keys module. The core problem manifests when arbitrary binaries are passed directly to String.to_atom/1 function without any validation or limiting mechanisms, creating a persistent atom table exhaustion condition that ultimately leads to complete system failure.
The technical implementation of this vulnerability occurs in multiple locations within the guardian library where binary data flows directly into atom creation functions. The base_key/1 function in lib/guardian/plug/keys.ex specifically converts any binary input into an atom using the pattern :"guardian_<input>" without any bounds checking or sanitization. This design flaw extends to helper functions claims_key/1, resource_key/1, and token_key/1 which create additional atoms on top of the base key, and key_from_other/1 which processes regex-captured binaries through String.to_atom/1. These functions accept String.t() as valid input according to their public specifications, making this behavior part of the documented API rather than an obscure implementation detail.
The operational impact of this vulnerability is severe and deterministic, as it creates a permanent resource exhaustion condition that cannot be recovered from without system restart. Each distinct attacker-influenced binary value results in one permanent atom being created in the BEAM's fixed-size atom table which contains approximately 1,048,576 entries by default. When this table fills completely, any subsequent atom creation attempts will crash the entire BEAM node, thereby taking down all applications running within that node. This makes the vulnerability particularly dangerous in multi-tenant environments or systems where unauthenticated input flows directly into key derivation functions through tenant identifiers, HTTP headers, or other request parameters.
The vulnerability aligns with CWE-400 (Uncontrolled Resource Consumption) and maps to ATT&CK technique T1499.004 (Endpoint Denial of Service) in the MITRE ATT&CK framework. The attack pattern follows a straightforward methodology where an attacker supplies varied binary inputs through accessible API endpoints, connection parameters, or session management functions that ultimately feed into the vulnerable atom creation pipeline. The impact severity is amplified because atoms in Elixir/BEAM are never garbage collected, meaning once consumed they permanently occupy memory space until the node restarts. This vulnerability affects guardian versions from 0.1.0 through 2.4.0, representing a long-standing issue that would have allowed attackers to maintain persistent DoS conditions against systems relying on this authentication library.
Mitigation strategies must focus on implementing strict input validation and resource limiting mechanisms within the key derivation functions. The most effective approach involves adding bounds checking and maximum length restrictions to binary inputs before passing them to String.to_atom/1, or alternatively implementing a bounded cache for atom creation that limits the total number of created atoms. Additionally, application developers should consider using string-based keys instead of atoms where possible, as strings can be garbage collected while atoms cannot. The fix should also include input sanitization to prevent attackers from supplying maliciously crafted binary values that could trigger multiple atom creations, and all user-supplied data flowing into these functions should undergo proper validation before being processed through the atom creation pipeline.