CVE-2026-93471: Unbounded SAML message decompression in esaml allows memory exhaustion
Improper Handling of Highly Compressed Data (Data Amplification) in esamlbinding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse.
esamlbinding:decoderesponse/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 binarytolist/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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated exploitation?
Deployments that expose esaml SAML assertion consumer service (ACS) or single-logout endpoints are exposed, because those endpoints accept unauthenticated requests by design. The vulnerable decoding occurs before SAML signature verification.
What does an attacker need to send?
An attacker needs to submit a crafted compressed SAMLResponse to a vulnerable ACS or single-logout endpoint. No authentication or valid SAML signature is required for the decompression path to run.
Are all esaml versions affected?
The issue affects esaml from version 0.1.0 onward. The provided data does not identify a fixed version.
How can I determine whether a service is vulnerable?
Check whether the application uses esaml version 0.1.0 or later and exposes SAML ACS or single-logout endpoints. Vulnerable processing uses esaml_binding:decode_response/2 on attacker-supplied SAMLResponse values before signature validation.