Vulnerabilities

Vulnerability · CVE-2026-105270

Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion

Published Oct 22, 2026 · catalog updated Oct 22, 2026 · Unbounded atom creation while

Last checked Nov 3, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-105270. EPSS is 0.53%. Act only if a listed version of Unbounded atom creation while is installed.

Severity

High8.7

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.53%

Remediation

Not established

Affected products

Hex esaml

## Summary Allocation of Resources Without Limits or Throttling vulnerability in in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted . parses the decoded with , which interns every element name, attribute name, and namespace prefix it reads as a permanent atom. The SAML consume (ACS) and single-logout endpoints call it on unauthenticated requests before any signature check, so one well-formed document with thousands of distinct names mints thousands of atoms while staying inside the 128 KB request body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests abort the node. This issue affects esaml: from 0.1.0 onward. ## Details **1. Input.** The SAML consume (ACS) and single-logout endpoints in read the request body, capped at 128 KB, and pass the form field to . Both the DEFLATE clause and the default clause end in with set. **2. Interning.** converts every element name, attribute name, and namespace prefix it tokenizes into an atom with , and the same happens for each namespace local name in . A well-formed document with many distinct names therefore mints one permanent atom per name. Repetitive names deflate well, so a document with ten thousand distinct names fits in a few tens of kilobytes on the wire. **3. Exhaustion before any check.** Signature verification and assertion validation run on the parsed document afterward, so the atoms are minted whether or not the document is a valid or signed SAML message. Atoms are never garbage collected and the VM aborts when the atom table reaches its limit of about one million entries, so a few dozen requests take the node down. ## Proof of concept 1. Build a well-formed XML document whose root contains several thousand empty elements with distinct names, each carrying a distinctly named attribute, for example through . 2. Deflate and base64-encode it, and post it to the service provider's SAM