CVE-2026-53425 in samly
Summary
by MITRE • 08/20/2026
Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.
Samly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim's session; the assertion signature itself remains intact, so this is not a signature-forgery issue.
This issue affects samly: from v0.3.0 onward.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Dropbox Samly represents a critical failure in the verification of data authenticity within the SAML 2.0 authentication flow. Specifically, the flaw resides in the SPHandler.validate_authresp/3 function located in lib/samly/sp_handler.ex. This component is responsible for validating SAML responses during service provider-initiated flows. The core technical deficiency lies in the incomplete validation logic employed by this handler. While the system checks the RelayState value, the Identity Provider identifier, and the presence of a target URL stored in the session context, it completely omits the verification of the InResponseTo attribute within the SubjectConfirmationData element of the SAML response. According to SAML 2.0 Core specification section 4.1.4.3, a service provider is strictly required to reject any assertion whose InResponseTo value does not correspond to an authentication request previously issued by that specific service provider instance. This omission creates a significant gap in the security posture of the application, as it fails to ensure that the received response is directly linked to and authorized for the current session initiated by the user.
The operational impact of this vulnerability allows an attacker to establish an authenticated session using a SAML response that was never requested by the service provider. The exploitation mechanism relies on the fact that the ID of the AuthnRequest issued by the service provider is not persisted in any accessible state, making it impossible for the application to perform the necessary comparison against the InResponseTo field in the incoming assertion. Consequently, an attacker can leverage a validly signed SAML assertion obtained from their own account with the trusted Identity Provider and inject this response into the victim's session flow. For this attack to succeed, the attacker must also ensure that the RelayState value matches the one present in the victim's active session, which serves as the primary identifier for correlating the request and response in this flawed implementation. Because the assertion signature remains intact and validly signed by the trusted IdP, traditional integrity checks do not detect the anomaly. This effectively allows an attacker to bypass authentication controls by replaying a legitimate but unrelated SAML response into an active session context, leading to unauthorized access or privilege escalation depending on the victim's role within the application.
This vulnerability is classified under CWE-287: Improper Authentication and CWE-345: Insufficient Verification of Data Authenticity, as it involves accepting data that has not been properly verified against its expected originator context. In terms of attack patterns, this aligns with MITRE ATT&CK technique T1606: Forge Web Credentials, specifically the sub-technique involving SAML token manipulation or replay attacks where valid credentials are misused in an unauthorized context. The underlying esaml library also contributes to this weakness by failing to inspect the InResponseTo field, thereby propagating the lack of validation from the application layer down to the cryptographic verification stage. This systemic failure means that even robust signature and audience checks cannot compensate for the missing logical binding between the request and response identifiers.
Mitigation strategies must focus on implementing strict state management and rigorous adherence to SAML specifications. The service provider must persist the ID of each AuthnRequest issued, typically within a secure session store or cache with an appropriate expiration time. Upon receiving a SAML response, the application must extract the InResponseTo value from the SubjectConfirmationData element and compare it against the stored request ID associated with the current user session. If there is no match, or if no corresponding request exists in the state storage, the authentication process must be immediately terminated, and an error returned to prevent any further processing of the assertion. Additionally, developers should review the configuration of the underlying esaml library to ensure that all available validation hooks are utilized correctly, although relying solely on third-party libraries is insufficient without explicit application-level checks for critical fields like InResponseTo. This fix ensures that SAML responses are strictly bound to their originating requests, thereby neutralizing replay attacks and unauthorized session hijacking attempts facilitated by this vulnerability. The issue affects versions of samly from v0.3.0 onward, necessitating an immediate update or patch application for all affected deployments to restore the integrity of the authentication workflow.