CVE-2026-86696

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.

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.

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.