CVE-2026-86696 in esaml
Summary
by MITRE • 10/22/2026
Allocation of Resources Without Limits or Throttling vulnerability in esaml in dropbox esaml allows an unauthenticated attacker to exhaust the Erlang VM atom table and crash the node via unsigned LogoutResponse messages.
esaml:status_code_map/1 in src/esaml.erl maps any StatusCode value it does not recognize to an atom with list_to_atom/1 on the last colon-separated segment of the URN. esaml_sp:validate_logout_response/2 verifies a signature only when the message carries one, so an unsigned LogoutResponse posted to the single-logout endpoint reaches esaml:decode_logout_response/1 and mints one permanent atom per distinct status value. Atoms are never reclaimed and the VM caps the atom table at about one million entries, so an attacker who posts that many distinct values aborts the node.
This issue affects esaml: from 0.1.0 onward.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Dropbox's implementation of the SAML library, specifically within the esaml component, represents a critical resource exhaustion flaw rooted in improper handling of untrusted input during authentication protocol operations. This specific weakness is classified under CWE-770 as Allocation of Resources Without Limits or Throttling and aligns with MITRE ATT&CK technique T1496, which involves Resource Hijacking through denial-of-service mechanisms that degrade service availability for legitimate users. The core issue arises from the library's design choice to dynamically generate Erlang atoms based on incoming SAML status codes without implementing any validation or throttling constraints, creating a direct path for an unauthenticated attacker to destabilize the underlying virtual machine infrastructure.
The technical mechanism of this exploitation relies on the specific behavior of the esaml:status_code_map/1 function located in src/esaml.erl. When processing SAML messages, particularly LogoutResponse payloads sent via single-logout endpoints, the system attempts to map StatusCode URNs into internal data structures. For any status code value that is not explicitly recognized by a predefined static mapping table, the library invokes list_to_atom/1 on the final colon-separated segment of the URN string. In the Erlang programming language, atoms are global constants used for pattern matching and identification, but they possess a critical limitation: once an atom is created, it remains in memory permanently until the node restarts. There is no garbage collection mechanism to reclaim these entries, meaning that every unique input value results in a permanent increase in memory consumption within the Erlang VM's internal tables.
The vulnerability is exacerbated by the signature verification logic implemented in esaml_sp:validate_logout_response/2. This function only enforces cryptographic signature validation when a digital signature is present in the incoming message structure. Consequently, an attacker can craft unsigned LogoutResponse messages that bypass this security control entirely. These unsigned messages are passed directly to esaml:decode_logout_response/1 without integrity checks, allowing malicious actors to inject arbitrary status code URNs into the system. By repeatedly sending distinct LogoutResponse payloads with unique StatusCode values, each request triggers the creation of a new atom in the VM's global namespace. This process is entirely unthrottled and lacks rate limiting or input length restrictions that would typically mitigate such abuse vectors.
The operational impact of this flaw is severe, leading to a complete denial-of-service condition for any service relying on the affected esaml version. The Erlang Virtual Machine imposes a hard limit on the number of atoms it can hold, which defaults to approximately one million entries in standard configurations. Once an attacker exhausts this atom table by submitting sufficiently distinct status codes, the VM triggers an abort sequence, causing the entire node or application instance to crash abruptly. This results in immediate service unavailability for all users connected to that specific server process. Because atoms are never reclaimed during runtime, a simple restart is required to restore normal operations, making this vulnerability particularly dangerous as it allows persistent disruption with minimal effort from the attacker and requires administrative intervention to resolve.
This security defect affects versions of esaml starting from 0.1.0 onwards, indicating that any deployment utilizing these library versions for SAML authentication flows involving single logout is potentially vulnerable. Mitigation strategies must focus on preventing the creation of unbounded atoms from external input. Developers should implement strict allow-listing for known StatusCode URNs rather than relying on dynamic atom generation via list_to_atom/1. Alternatively, if dynamic mapping is necessary, the implementation should use maps or dictionaries with string keys instead of atoms to ensure that memory usage remains bounded and reclaimable. Additionally, enforcing mandatory signature verification for all LogoutResponse messages would prevent unsigned payloads from reaching the vulnerable decoding logic, thereby closing this specific attack vector until a patched version of the library is deployed across the infrastructure.