CVE-2026-54894: ueberauth guardian · Unthrottled Resource Allocation
Affects ueberauth guardianSource CVE Database V5
Not known to be exploited · CVSS 6.9 Medium : upgrade to 2.4.1 when convenient.
Data as of 31 Oct 2026, 08:20 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.4.1, 2952657e42e6341a67e6aaad09d8f0b40ae917cb
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:HExploitation evidence
Disclosed: evidence found.
CVE published 1 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.
What to do
Upgrade guardian to 2.4.1; guardian to 2952657e42e6341a67e6aaad09d8f0b40ae917cb.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| ueberauthguardian | Affected
| Fixed in
|
| ueberauthguardian | Affected
| Fixed in
|
Hexguardianpkg:hex/guardianOther threats | Affected
| Fixed in
|
CPE configurations (1)
cpe:2.3:a:ueberauth:guardian:*:*:*:*:*:*:*:*
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
If you cannot patch yet, avoid passing untrusted or attacker-controlled input to functions that convert binaries to atoms. Consider using String.to_existing_atom/1 or other safe alternatives that do not create new atoms dynamically.
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.
References
- github.com/ueberauth/guardian/security/advisories/GHSA-xqch-c77q-rgh5 (opens in a new tab)
- cna.erlef.org/cves/CVE-2026-54894.html (opens in a new tab)
- osv.dev/vulnerability/EEF-CVE-2026-54894 (opens in a new tab)
- github.com/ueberauth/guardian/commit/2952657e42e6341a67e6aaad09d8f0b40ae917cb (opens in a new tab)