Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion
What fixes it
No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.
Description
Allocation of Resources Without Limits or Throttling vulnerability in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via a crafted SAMLResponse.
esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, 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.
Text from CVE List
Affected versions 2
- esamlaffected: deeb84378d5c82153b470e99d24f77c38afca14a and laterCVE List
- esamlaffected: 0.1.0 and laterCVE List
References 5
- github.com/arekinath/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14aFixvia CVE List
- github.com/handnot2/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14aFixvia CVE List
- github.com/dropbox/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14aFixvia CVE List
- cna.erlef.org/cves/CVE-2026-105270.htmlAdvisoryvia CVE List
- osv.dev/vulnerability/EEF-CVE-2026-105270Referencevia CVE List