Vulnerabilities

Vulnerability · CVE-2026-93471

Unbounded SAML message decompression in esaml allows memory exhaustion

Published Oct 22, 2026 · catalog updated Oct 22, 2026 · Unbounded SAML message decompression

Last checked Nov 3, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-93471. EPSS is 0.66%. Act only if a listed version of Unbounded SAML message decompression is installed.

Severity

High8.7

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.66%

Remediation

Not established

Affected products

Hex esaml

## Summary Improper Handling of Highly Compressed Data (Data Amplification) in in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed . base64-decodes the attacker-supplied , inflates it with with no bound on the output, then converts the result to a charlist with 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. ## Details **1. Input.** The SAML consume (ACS) and single-logout endpoints read the request body and pass the form field to . The attacker's field selects the clause. Both clauses inflate: the explicit DEFLATE clause, and the default clause, which tries inside a whenever the body is not plain XML. **2. Unbounded inflate.** evaluates . inflates the whole stream in one call with no cap on output size, and then expands the inflated binary to a charlist, which costs about 16 bytes of heap per byte on a 64-bit VM. **3. Exhaustion before any check.** All of this happens before parses the document and before verifies any signature. A deflate stream of a long run of identical bytes reaches a ratio near 1000 to 1, so a request body of tens of kilobytes produces hundreds of megabytes of binary and then several gigabytes of list heap. A few concurrent requests exhaust memory and crash the node. ## Proof of concept 1. Build a as the base64 of a raw deflate stream of a long run of identical bytes (for example 60 MB of zero bytes), which encodes to roughly 79 KB on the wire. 2. Post it to the service provider's SAML consume (ACS) endpoint as the form field, with set to the DEFLATE URI, or omitted to ta