VDB
KO

EEF-CVE-2026-55733

Atom-table exhaustion denial of service in Guardian permissions AtomEncoding via unbounded atom creation

Quick fix

EEF-CVE-2026-55733 — guardian: upgrade to the fixed version with the command below.

mix deps.update guardian

Details

## Summary

Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-controlled binary input.

Guardian.Permissions.AtomEncoding encodes permission scopes by passing arbitrary binaries to String.to\_atom/1. When encode/3 in lib/guardian/permissions/atom\_encoding.ex is called with a list, each binary entry is handled by the encode\_value/3 binary clause, which calls String.to\_atom(value) with no allow-list check. The perm\_set argument (the application's small, finite set of legitimate permission names) is discarded, so any external string flows straight into atom creation. This encoder is selected with use Guardian.Permissions, encoding: Guardian.Permissions.AtomEncoding and reached through the imported encode/3 entry point.

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 funnels attacker-influenced permission scopes (from a request body, a JWT claim, or other external input) into encode/3 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 with system\_limit, taking down every application running on it.

The default encoder is Guardian.Permissions.BitwiseEncoding, which is not affected.

This issue affects guardian: from 2.0.0 before 2.4.1.

## Workaround

Switch the permission encoder to the default Guardian.Permissions.BitwiseEncoding or to Guardian.Permissions.TextEncoding, neither of which creates atoms. Alternatively, validate every permission value against the configured perm\_set allowlist (rejecting unknown values) before passing it to encode/3.

## Configuration

Only applications that opt into the non-default Guardian.Permissions.AtomEncoding encoder (via use Guardian.Permissions, encoding: Guardian.Permissions.AtomEncoding) and pass attacker-influenced permission scopes into its encode/3 entry point are exploitable. The default Guardian.Permissions.BitwiseEncoding encoder and the Guardian.Permissions.TextEncoding encoder do not create atoms and are not affected.

Are you affected?

Enter the version of the package you're using.

Affected packages

Hex / guardian
Introduced in: 2.0.0 Fixed in: 2.4.1
Fix mix deps.update guardian

References