CVE-2026-53425: Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses
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.validateauthresp/3 in lib/samly/sphandler.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.
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs a validly signed SAML assertion from the service provider's trusted identity provider, which they can obtain for their own account. They also need a RelayState value matching the victim's session; no assertion-signature forgery is required.
Which existing SAML checks do not prevent exploitation?
The underlying esaml library still validates status, signature, recipient, audience, and staleness. Those checks do not validate SubjectConfirmationData/@InResponseTo against an AuthnRequest issued by the service provider.
How can defenders determine whether their deployment is exposed?
Review the Samly version in use and its SP-initiated response validation path. Affected behavior is present when Samly does not persist the AuthnRequest ID and does not compare it with SubjectConfirmationData/@InResponseTo during authentication-response validation.