Unbounded SAML message decompression in esaml allows memory exhaustion
## Summary Improper Handling of Highly Compressed Data (Data Amplification) in `esaml_binding` in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed `SAMLResponse`. `esaml_binding:decode_response/2` base64-decodes the attacker-supplied `SAMLResponse`, inflates it with `zlib:unzip/1` with no bound on the output, then converts the result to a charlist with `binary_to_list/1` before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down. This issue affects esaml: from 0.1.0 onward. ## Details **1. Input.** The SAML consume (ACS) and single-logout endpoints read the request body and pass the `SAMLResponse` form field to `esaml_binding:decode_response/2`. The attacker's `SAMLEncoding` field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries `zlib:unzip/1` inside a `catch` whenever the body is not plain XML. **2. Unbounded inflate.** `decode_response/2` evaluates `binary_to_list(zlib:unzip(base64:decode(SAMLResponse)))`. `zlib:unzip/1` inflates the whole stream in one call with no cap on output size, and `binary_to
- Products
- esaml
- Affected versions
- 3.0.1, 3.1.0, 3.2.0, 3.3.0, 3.4.0, 3.5.0, 3.6.0, 3.6.1, 3.7.0, 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0, 4.6.0
- Fixed versions
- Not specified
- CVEs
- CVE-2026-93471
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 31 Oct 2026, 17:45 UTC · Revision 1
Source evidence
Unbounded SAML message decompression in esaml allows memory exhaustion
core-osv · Original sourcePublished 22 Oct 2026, 06:59 UTC
## Summary Improper Handling of Highly Compressed Data (Data Amplification) in `esaml_binding` in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed `SAMLResponse`. `esaml_binding:decode_response/2` base64-decodes the attacker-supplied `SAMLResponse`, inflates it with `zlib:unzip/1` with no bound on the output, then converts the result to a charlist with `binary_to_list/1` before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down. This issue affects esaml: from 0.1.0 onward. ## Details **1. Input.** The SAML consume (ACS) and single-logout endpoints read the request body and pass the `SAMLResponse` form field to `esaml_binding:decode_response/2`. The attacker's `SAMLEncoding` field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries `zlib:unzip/1` inside a `catch` whenever the body is not plain XML. **2. Unbounded inflate.** `decode_response/2` evaluates `binary_to_list(zlib:unzip(base64:decode(SAMLResponse)))`. `zlib:unzip/1` inflates the whole stream in one call with no cap on output size, and `binary_to
osv:EEF-CVE-2026-93471
esaml
Fixed versions: Not specified
Complete source record
{
"id": "cf4a2532141e0a9c151359a4a36aedc88136fc05913f77dd7b3be9231398887e",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-93471",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Unbounded SAML message decompression in esaml allows memory exhaustion",
"summary": "## Summary Improper Handling of Highly Compressed Data (Data Amplification) in `esaml_binding` in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed `SAMLResponse`. `esaml_binding:decode_response/2` base64-decodes the attacker-supplied `SAMLResponse`, inflates it with `zlib:unzip/1` with no bound on the output, then converts the result to a charlist with `binary_to_list/1` before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down. This issue affects esaml: from 0.1.0 onward. ## Details **1. Input.** The SAML consume (ACS) and single-logout endpoints read the request body and pass the `SAMLResponse` form field to `esaml_binding:decode_response/2`. The attacker's `SAMLEncoding` field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries `zlib:unzip/1` inside a `catch` whenever the body is not plain XML. **2. Unbounded inflate.** `decode_response/2` evaluates `binary_to_list(zlib:unzip(base64:decode(SAMLResponse)))`. `zlib:unzip/1` inflates the whole stream in one call with no cap on output size, and `binary_to",
"evidence": "osv:EEF-CVE-2026-93471",
"products": [
{
"name": {
"value": "esaml",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": [
{
"value": "3.0.1",
"evidence": "/affected/0/versions"
},
{
"value": "3.1.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.2.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.3.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.4.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.5.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.6.0",
"evidence": "/affected/0/versions"
},
{
"value": "3.6.1",
"evidence": "/affected/0/versions"
},
{
"value": "3.7.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.0.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.1.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.2.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.3.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.4.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.5.0",
"evidence": "/affected/0/versions"
},
{
"value": "4.6.0",
"evidence": "/affected/0/versions"
}
]
}
],
"severity": "high",
"structured": {
"id": "EEF-CVE-2026-93471",
"aliases": [
"CVE-2026-93471",
"EEF-CVE-2026-93471"
],
"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": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.1.0"
}
]
}
],
"package": {
"name": "esaml",
"purl": "pkg:hex/esaml",
"ecosystem": "Hex"
},
"versions": [
"3.0.1",
"3.1.0",
"3.2.0",
"3.3.0",
"3.4.0",
"3.5.0",
"3.6.0",
"3.6.1",
"3.7.0",
"4.0.0",
"4.1.0",
"4.2.0",
"4.3.0",
"4.4.0",
"4.5.0",
"4.6.0"
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-93471.json"
}
},
{
"ranges": [
{
"repo": "https://github.com/handnot2/esaml",
"type": "GIT",
"events": [
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
]
}
],
"versions": [
"v4.2.0",
"v3.6.1",
"v4.1.0",
"v4.0.0",
"v3.6.0",
"v3.5.0",
"v3.4.0",
"v3.3.0",
"v3.2.0",
"v3.1.0",
"v3.0.1",
"v3.0.0",
"v2.1.0",
"2.0.0",
"v1.1",
"v1.0",
"v0.1"
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-93471.json"
}
},
{
"ranges": [
{
"repo": "https://github.com/arekinath/esaml",
"type": "GIT",
"events": [
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
]
}
],
"versions": [
"v1.1",
"v1.0",
"v0.1"
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-93471.json"
}
},
{
"ranges": [
{
"repo": "https://github.com/dropbox/esaml",
"type": "GIT",
"events": [
{
"introduced": "deeb84378d5c82153b470e99d24f77c38afca14a"
}
]
}
],
"database_specific": {
"source": "https://cna.erlef.org/osv/EEF-CVE-2026-93471.json"
}
}
],
"modified": "2026-10-22T07:00:03.393965193Z",
"provider": "osv",
"references": [
"https://cna.erlef.org/cves/CVE-2026-93471.html",
"https://github.com/handnot2/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://github.com/arekinath/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://github.com/dropbox/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a",
"https://hex.pm/packages/esaml"
],
"provider_metadata": {
"cpe_ids": [
"cpe:2.3:a:handnot2:esaml:*:*:*:*:*:*:*:*",
"cpe:2.3:a:arekinath:esaml:*:*:*:*:*:*:*:*",
"cpe:2.3:a:dropbox:esaml:*:*:*:*:*:*:*:*"
],
"cwe_ids": [
"CWE-409"
],
"capec_ids": [
"CAPEC-231"
]
}
},
"related_cves": [
{
"value": "CVE-2026-93471",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 404581,
"published_at": "2026-10-22T06:59:24.029+00:00"
}