Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml…

Why it is Amber

• CVSS 8.7 high
• Remotely exploitable without logging in

References

• https://cna.erlef.org/cves/CVE-2026-93471.html
• https://github.com/arekinath/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a
• https://github.com/dropbox/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a
• https://github.com/handnot2/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a
• https://osv.dev/vulnerability/EEF-CVE-2026-93471

Original description

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.