---
id: "CVE-2026-93471"
kind: "vulnerability"
aliases: ["CVE-2026-93471"]
title: "esaml: crafted SAMLResponse exhausts memory and crashes Erlang VM"
severity: "high"
cvss: 8.7
epss: 0.00438
exploited: false
status: "open"
category: "package"
products: [{"name": "esaml", "fixed": [], "affected": ">= 0.1.0", "ecosystem": "hex"}]
ecosystems: ["hex"]
tags: ["cowboy", "elixir", "erlang", "esaml", "package", "saml", "sso"]
not_affected_if: ["esaml-not-used", "no-saml-endpoints", "no-saml-sp"]
published_at: "2026-10-22T09:17:16+00:00"
first_seen_at: "2026-10-23T21:57:30+00:00"
updated_at: "2026-10-24T07:15:51+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93471", "first_seen_at": "2026-10-23T21:57:30+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T23:44:19+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-93471", "first_seen_at": "2026-10-24T07:15:51+00:00"}]
---

# esaml: crafted SAMLResponse exhausts memory and crashes Erlang VM

esaml_binding:decode_response/2 inflates the attacker-supplied SAMLResponse with zlib:unzip/1 with no output cap, then binary_to_list/1, before any signature check. A request of tens of KB expands to GBs, so a few unauthenticated requests to the ACS or single-logout endpoint crash the Erlang VM. CVSS 4.0 8.7. All esaml versions from 0.1.0 are affected, including Hex 4.6.0; no fixed release is published as of 2026-10-23.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- hex:esaml affected >= 0.1.0 fixed ?

## How to check

grep -i esaml rebar.lock mix.lock. Any esaml version is affected. Exposed if your app routes SAML ACS or SLO requests to esaml_cowboy:validate_assertion/2 or validate_logout/2, or calls esaml_binding:decode_response/2 on request bodies.

## Fix

No patched Hex release known (4.6.0 still flagged). Until one exists: cap the request body size in front of the ACS/SLO endpoints (a reverse proxy limit of a few hundred KB), rate-limit them, and set a max_heap_size on request-handling processes. Watch hex.pm/packages/esaml and the dropbox/esaml, arekinath/esaml and handnot2/esaml repos for a fix.

## Timeline

- 2026-10-23T21:57:30+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-93471
- 2026-10-23T23:44:19+00:00 analyst — EEF CNA advisory + Hex read. No fixed release named: Hex latest 4.6.0 is still flagged, affected >=0.1.0. Commit deeb843 is linked as fix but the CNA lists it as the affected-from git version, so it may be the introducing commit, not the patch; unverified. No X chatter, no exploitation reported; PoC described in advisory only. Sibling CVE-2026-105270 (atom table) cites the same commit.
- 2026-10-24T07:15:51+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-93471

## Documents

- [advisory] EEF CNA: CVE-2026-93471 esaml unbounded decompression https://cna.erlef.org/cves/CVE-2026-93471.html
- [fix] esaml fix commit deeb843 https://github.com/dropbox/esaml/commit/deeb84378d5c82153b470e99d24f77c38afca14a
- [mentions] Hex advisories for esaml https://hex.pm/packages/esaml/advisories

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_