CVE-2026-93471
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk37th percentile - higher than 37% of all known CVEs
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.
Risk Assessment
An unauthenticated attacker can remotely cause denial of service through memory exhaustion, leading to unavailability of the SAML authentication service. This can block access to applications relying on that identity provider.
Recommendation
Update the esaml library to a version that limits the size of inflated data. Until the update, consider implementing request size limits at the reverse proxy or load balancer level.
Other vulnerabilities in esaml
See all- CVE-2026-86696High
Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages. esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node. This issue affects esaml: from 0.1.0 onward.
- CVE-2026-105270High
In the esaml library (dropbox), esaml_binding:decode_response/2 parses the decoded SAMLResponse with xmerl_scan:string/2, which interns every element name, attribute name, and namespace prefix as a permanent atom. The ACS and single-logout endpoints call it on unauthenticated requests before any signature check, so one document with thousands of distinct names mints thousands of atoms within the 128 KB body limit. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so a few dozen requests can abort the node.
- CVE-2026-28809Medium
The esaml library (and its forks) has an XXE vulnerability. Before signature verification, esaml parses attacker-controlled SAML messages using xmerl_scan:string/2 without disabling XML entity expansion. On Erlang/OTP before version 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can read local files (e.g., Kubernetes secrets) and include their contents in the SAML document.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS