Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion
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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-105270
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 04:44 UTC · Revision 1
Source evidence
Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion
core-osv · Original sourcePublished 22 Oct 2026, 06:58 UTC
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.
osv:CVE-2026-105270
Complete source record
{
"id": "4ffe8f768d1fedf6c06a525a682301709586c07cc8ebf380b26531a457095f4e",
"url": "https://osv.dev/vulnerability/CVE-2026-105270",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Unbounded atom creation while parsing SAML messages in esaml allows atom table exhaustion",
"summary": "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.",
"evidence": "osv:CVE-2026-105270",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-105270",
"aliases": [
"CVE-2026-105270",
"EEF-CVE-2026-105270"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/arekinath/esaml",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"fixed": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
},
{
"repo": "https://github.com/handnot2/esaml",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"fixed": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-105270.json"
}
}
],
"modified": "2026-11-01T02:30:17.012089243Z",
"provider": "osv",
"references": [
"https://github.com",
"https://osv.dev/vulnerability/EEF-CVE-2026-105270",
"https://repo.hex.pm",
"https://cna.erlef.org/cves/CVE-2026-105270.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/105xxx/CVE-2026-105270.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-105270",
"https://github.com/arekinath/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://github.com/dropbox/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://github.com/handnot2/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://github.com/arekinath/esaml",
"https://github.com/dropbox/esaml",
"https://github.com/handnot2/esaml"
],
"provider_metadata": {
"cwe_ids": [
"CWE-770"
],
"cna_assigner": "EEF",
"unresolved_ranges": [
{
"extracted_events": [
{
"range": [
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
},
{
"fixed": "*"
},
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
},
{
"fixed": "*"
},
{
"introduced": "0.1.0"
},
{
"fixed": "*"
},
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
},
{
"fixed": "*"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/105xxx/CVE-2026-105270.json"
}
},
"related_cves": [
{
"value": "CVE-2026-105270",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 492570,
"published_at": "2026-10-22T06:58:43.034+00:00"
}