CVE-2026-93471 in esaml
Summary
by MITRE • 10/22/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Dropbox's implementation of SAML authentication involves an improper handling of highly compressed data within the esaml library, specifically affecting versions starting from 0.1.0. This flaw constitutes a classic data amplification attack vector that allows unauthenticated attackers to exhaust server memory and crash the Erlang Virtual Machine. The root cause lies in the esaml_binding:decode_response/2 function, which processes incoming SAML responses without implementing adequate safeguards against compression bombs or zip bombs. By accepting requests on endpoints designed for public access, such as the Assertion Consumer Service (ACS) and single-logout endpoints, the system exposes itself to exploitation by any external actor who can send crafted HTTP requests.
The technical mechanism of this vulnerability relies on the sequence of operations performed during SAML response parsing. First, the attacker-supplied SAMLResponse is base64-decoded. Immediately following this step, the code attempts to inflate the data using zlib:unzip/1 without imposing any limit on the size of the decompressed output. This lack of a bound allows an attacker to craft a small deflate stream that exhibits an extremely high compression ratio, potentially reaching 1000 to 1 or higher. When this compressed payload is inflated, it expands from tens of kilobytes into hundreds of megabytes and eventually several gigabytes of data. The subsequent conversion of this massive binary result into a charlist via binary_to_list/1 further exacerbates the memory consumption within the Erlang runtime environment, leading to heap exhaustion.
The operational impact of this vulnerability is severe, resulting in a denial-of-service condition for services relying on Dropbox SAML integration. Because the vulnerable code path executes before any signature verification or authentication checks are performed, an attacker does not need valid credentials to trigger the memory exhaustion. A few carefully crafted requests can deplete the available memory resources of the Erlang node hosting the service, causing the virtual machine to crash and taking down the associated application nodes. This effectively disrupts availability for all users dependent on that specific authentication infrastructure, as the failure is systemic to the node rather than isolated to a single user session.
From a classification perspective, this vulnerability aligns with CWE-409, which describes Improper Handling of Highly Compressed Data (Data Amplification). The attack methodology corresponds to MITRE ATT&CK techniques related to Resource Exhaustion Attacks, where an adversary aims to degrade or deny service by consuming system resources such as memory or CPU. To mitigate this risk, developers must implement strict limits on the maximum size of decompressed data before processing it further. This includes setting explicit byte thresholds for zlib:unzip operations and validating input sizes prior to inflation. Additionally, moving signature verification earlier in the request processing pipeline can help prevent unnecessary resource consumption from malicious payloads that fail authentication checks. Upgrading to a patched version of esaml or applying custom patches that enforce these size constraints is essential for restoring secure operation.