CVE-2026-53424 in Samly
Summary
by MITRE • 08/20/2026
Authentication Bypass by Capture-replay vulnerability in dropbox samly allows an attacker to authenticate as the subject of a captured SAML assertion by resubmitting it.
Samly.Helper.decode_idp_auth_resp/3 in lib/samly/helper.ex calls esaml_sp:validate_assertion/2, whose default duplicate detector is a no-op. The /3 arity accepting a DuplicateFun exists in esaml and implements the check, but Samly never calls it and offers no configuration to supply one, so the SAML 2.0 Web Browser SSO Profile requirement that a bearer assertion be used once is unenforced. An attacker holding a valid SAMLResponse obtained from the network, from browser history, or from logs can submit the identical bytes repeatedly until the assertion's NotOnOrAfter passes, each time establishing a session as the assertion's subject.
This issue affects samly: from v0.3.0 onward.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in the Samly library represents a critical authentication bypass mechanism rooted in the failure to enforce single-use constraints for SAML assertions. This flaw specifically impacts versions of the software starting from release 0.3.0 and allows an attacker to authenticate as any user whose valid Security Assertion Markup Language assertion has been captured. The core technical deficiency lies within the Samly.Helper.decode_idp_auth_resp/3 function located in lib/samly/helper.ex, which interfaces with the underlying esaml_sp:validate_assertion/2 module. While the esaml library provides a mechanism to detect duplicate assertions through an optional DuplicateFun argument, the Samly implementation fails to utilize this capability. The default behavior of the validation process treats duplicate detection as a no-op operation, effectively disabling the security control designed to prevent assertion replay attacks.
From a technical perspective, SAML 2.0 Web Browser Single Sign-On Profile mandates that bearer assertions must be used only once to maintain session integrity and prevent unauthorized access through resubmission. The absence of an active duplicate detector means that identical bytes from a previously valid SAMLResponse can be submitted repeatedly by an adversary. This lack of enforcement allows the system to accept multiple authentication requests based on the same cryptographic proof, thereby bypassing the intended one-time use policy. An attacker who obtains a valid assertion through network interception, browser history access, or log file exposure can exploit this gap by resubmitting the captured data until the NotOnOrAfter timestamp expires. Each successful submission establishes a new session for the subject of that assertion, granting unauthorized access without requiring additional credentials or exploitation of other vulnerabilities.
The operational impact of this vulnerability is severe, as it directly compromises the confidentiality and integrity of user accounts protected by SAML-based authentication. Since the attack relies on resubmitting existing valid assertions rather than forging new ones, it does not require breaking cryptographic signatures or compromising identity provider secrets. Instead, it exploits a logical flaw in session management where the service provider fails to track previously processed assertion identifiers. This makes the vulnerability particularly dangerous because it can be executed by any actor with network-level visibility or access to client-side storage and server logs. The ability to authenticate as arbitrary subjects undermines trust in the identity federation architecture and can lead to unauthorized data access, privilege escalation, and potential compliance violations depending on the sensitivity of the affected systems.
To mitigate this risk, immediate remediation is required by updating the Samly library to a version that properly implements duplicate assertion detection or by applying custom patches if an update is not immediately available. Developers must ensure that the esaml_sp:validate_assertion/2 function is called with a valid DuplicateFun implementation that checks for previously processed assertions against a persistent store such as a cache or database. This check should verify unique identifiers within the SAML assertion, such as the Assertion ID and Issue Instant timestamp, to prevent replay attacks. Additionally, organizations should review their logging practices to minimize exposure of sensitive authentication tokens in plaintext logs and implement network-level protections like TLS inspection where appropriate to reduce the risk of interception. Aligning with industry standards, this vulnerability corresponds to CWE-294: Capture-replay Flaw and maps to MITRE ATT&CK technique T1078: Valid Accounts, specifically under the subtechnique for using existing valid credentials or tokens obtained through other means.