Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.6
CVE-2026-53425: Samly may accept unsolicited login responses
CVE-2026-53425 · published 1 month ago
Summary
The Samly library does not check that a login response matches a request it actually sent. This means an attacker who can obtain a signed response from the trusted identity provider could log a user in without the user initiating the login. Update Samly to a version that adds the missing check or apply a patch that validates the InResponseTo field.
What to do
- Update dropbox samly to version * or later.
- Update handnot2 samly to version * or later.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| – | dropbox | samly | < * |
| – | handnot2 | samly | < * |
| Hex | handnot2 | samly | >= 0.3.0 |
Original advisory text
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.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 0.3.0 onward.
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 0.3.0 onward.
Internet-facing
14 days
Internal
At next upgrade
- Not known to be exploited
- Needs hands-on effort to exploit
- Gives an attacker full control
Severity
7.6
High
Type
CWE-345Insufficient Verification of Data Authenticity
Timeline
Published20 Aug 2026
Updated27 Sep 2026
First seen20 Aug 2026
Track software like this
Free during beta