CVE-2026-54894

Guardian.Plug.Keys in the ueberauth Guardian authentication library (Elixir/BEAM) allocates BEAM atoms without limits: base_key/1, the derived claims_key/resource_key/token_key helpers, and key_from_other/1 all pass caller-supplied binaries to String.to_atom/1, and the library's public specs explicitly document strings as valid input. Any application that threads attacker-influenced data — such as a tenant identifier or request header — into Guardian key options (e.g., Guardian.Plug.current_token(conn, key: key)) mints a new, permanently retained atom for every distinct value. Because atoms are never garbage collected and the BEAM atom table caps out at roughly 1,048,576 entries by default, a modest stream of varied unauthenticated input exhausts the table and crashes the BEAM node, taking down every application running on it (CVSS 4.0: 6.9 medium, with high availability impact on the vulnerable and subsequent systems). All guardian versions from 0.1.0 before 2.4.1 are affected, while applications that only use fixed, built-in default keys are largely unaffected. No in-the-wild exploitation is currently reported (EPSS 0.3%, not in CISA KEV), but a public advisory with technical detail exists at GHSA-xqch-c77q-rgh5.

What to do: Upgrade to guardian 2.4.1 or later, since every version from 0.1.0 before 2.4.1 is affected. Audit your application for code paths where attacker-controlled values (tenant identifiers, request headers, other input) reach Guardian key options such as current_token(conn, key: key), and as an interim mitigation restrict those key values to a fixed, validated set. Operators can also monitor the BEAM atom table (e.g., :erlang.system_info(:atom_count)) against the ~1,048,576-entry default limit to catch exhaustion before a node crash.