CVE-2026-54894 is a high severity (CVSS 7.5) denial of service in the Elixir Guardian authentication library. Guardian.Plug.Keys converts arbitrary strings into atoms, so varied input can fill the BEAM atom table and crash the node. Upgrade guardian to 2.4.1. The steps below show how to check your version and what to change.
What's affected
- guardian (Hex package): versions 0.1.0 up to but not including 2.4.1. Fixed in 2.4.1.
The advisory describes the affected functions in lib/guardian/plug/keys.ex: base_key/1, the helpers claims_key/1, resource_key/1 and token_key/1 built on it, and key_from_other/1. Higher level entry points such as Guardian.Plug.current_token(conn, key: key) pass a caller-supplied key straight through, so reaching the problem uses documented API.
Exposure depends on whether an application derives a Guardian namespace key from attacker-influenced data such as a tenant identifier or a request header. The record and advisory agree on the version and severity.
How to check if you're exposed
For an Elixir project, print the resolved version:
mix deps | grep -A2 guardian
You can also search the lockfile:
grep guardian mix.lock
Then search your code for the entry points named above and see whether any attacker-influenced value can reach them.
What to do now
- Update the guardian package to 2.4.1 or later and rebuild your release.
- Never pass raw request data, header values or token claims into functions that create atoms. Map input to a fixed set of known values first.
- Add monitoring for BEAM atom count so growth is noticed before the node crashes.
- Remember that a crash takes down every application on the node, so consider isolating critical services.
Why it matters
The record lists CWE-770, allocation of resources without limits or throttling. Atoms on the BEAM are never garbage collected, and the atom table has a fixed default limit of about 1,048,576 entries. Each previously unseen string converted with String.to_atom/1 adds a permanent entry. An attacker who can send enough distinct values fills the table, and the runtime aborts, taking every application on the node with it.
This is a good example of a flaw where reachability decides risk. If no attacker-controlled value ever becomes a key, the code is present but not reachable. Reachability analysis helps tell those cases apart. The record does not mark this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is atom creation dangerous?
Atoms are never garbage collected and the table has a fixed size, so unbounded atom creation from input can crash the whole node.
Am I affected if I only use fixed keys?
If no external value is used to build a key, the vulnerable path is not reached, but upgrading is still the safer course.
Sources
Last reviewed: 18 October 2026.
