CVE-2026-55733: Atom-table exhaustion denial of service in Guardian permissions AtomEncoding via unbounded atom creation

Published Aug 1, 2026
·
Updated

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.toatom/1. When encode/3 in lib/guardian/permissions/atomencoding.ex is called with a list, each binary entry is handled by the encodevalue/3 binary clause, which calls String.toatom(value) with no allow-list check. The permset 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.toatom/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 systemlimit, 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.

Affected Software

1 affected component
guardian guardian>=2.0.0<2.4.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade guardian to a version that resolves this vulnerability.

    Fixed in 2.4.1
  2. Configuration

    Modify Guardian.Permissions.AtomEncoding so encode_value/3 does not call String.to_atom(value) without an allow-list/permission-name check; only encode from the application's finite perm_set and prevent external binary scope values from being used to create new atoms.

    Guardian.Permissions.AtomEncoding allow-list/check before String.to_atom/1 = enabled
  3. Configuration

    Use the default (non-atom-creating) encoder by configuring Guardian.Permissions to use Guardian.Permissions.BitwiseEncoding instead of Guardian.Permissions.AtomEncoding (the BitwiseEncoding encoder is noted as not affected by this atom-table exhaustion issue).

    Guardian.Permissions encoding = Guardian.Permissions.BitwiseEncoding
  4. Compensating control

    Implement request-level throttling/limits on untrusted inputs reaching Guardian permissions encoding (to prevent unbounded atom creation attempts via attacker-controlled scope binaries prior to fully upgrading/configuring encoders).

Event History

Aug 1, 2026
CVE Published
via MITRE·06:46 PM
Data Sourced
via MITRE·06:46 PM
DescriptionWeakness
Data Sourced
via NVD·07:16 PM
DescriptionSeverityWeakness
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-55733?

CVE-2026-55733 has a severity score of 75, indicating a high risk of denial of service.

2

How does CVE-2026-55733 allow an attacker to exploit a system?

CVE-2026-55733 allows an attacker to cause denial of service by creating an unbounded number of atoms through arbitrary binary input.

3

Which software is affected by CVE-2026-55733?

CVE-2026-55733 affects the Guardian permissions in the ueberauth guardian software.

4

How can I mitigate CVE-2026-55733?

Mitigation for CVE-2026-55733 involves implementing limits on atom creation and validating binary inputs before processing.

5

What are the consequences of failing to address CVE-2026-55733?

Failing to address CVE-2026-55733 can lead to service interruptions due to denial of service attacks by saturating atom resources.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203