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.
Project Subscriptions
No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Fri, 21 Aug 2026 20:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Thu, 20 Aug 2026 19:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | 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. |
Thu, 20 Aug 2026 17:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses | |
| First Time appeared |
Dropbox
Dropbox samly Handnot2 Handnot2 samly |
|
| Weaknesses | CWE-345 | |
| CPEs | cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:* cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:* |
|
| Vendors & Products |
Dropbox
Dropbox samly Handnot2 Handnot2 samly |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-21T19:50:34.320Z
Reserved: 2026-06-09T11:01:47.529Z
Link: CVE-2026-53425
Updated: 2026-08-21T19:50:30.104Z
Status : Received
Published: 2026-08-20T18:16:27.850
Modified: 2026-08-21T20:16:36.620
Link: CVE-2026-53425
No data.
OpenCVE Enrichment
Updated: 2026-08-21T13:01:23Z