{"id":"CVE-2026-53425","aliases":["EEF-CVE-2026-53425","EUVD-2026-63489","GHSA-4mhx-38g6-r4wq"],"status":"published","title":"Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses","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.\n\nSamly.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.\n\nThis issue affects samly: from 0.3.0 onward.","severity":{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00223,"percentile":0.1304,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-345"],"published":"2026-08-20T17:26:35Z","modified":"2026-10-26T10:10:00Z","affected":[{"source":"osv","ecosystem":"Hex","package":"samly","ranges":[{"type":"SEMVER","events":[{"introduced":"0.3.0"}]}],"versions":["0.10.0","0.10.1","0.4.0","0.5.0","0.6.0","0.6.1","0.6.2","0.6.3","0.7.0","0.7.1","0.7.2","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.9.0","0.9.1","0.9.2","0.9.3","1.0.0","1.0.0-rc.0","1.0.0-rc.1","1.1.0","1.2.0","1.3.0","1.4.0"]}],"products":[{"vendor":"dropbox","product":"samly"},{"vendor":"handnot2","product":"samly"}],"references":[{"url":"https://cna.erlef.org/cves/CVE-2026-53425.html","tags":["related","third-party-advisory","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-53425","tags":["related"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53425"},{"url":"https://github.com/advisories/GHSA-4mhx-38g6-r4wq"},{"url":"https://hex.pm/packages/samly","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-53425","title":"Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses","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.\n\nSamly.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.\n\nThis issue affects samly: from 0.3.0 onward.","status":"published","published":"2026-08-20T17:26:35.537Z","modified":"2026-08-21T19:50:34.32Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T14:19:59.761005Z"}],"euvd":[{"id":"EUVD-2026-63489","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.\n\nSamly.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.\n\nThis issue affects samly: from 0.3.0 onward.","status":"published","published":"2026-08-20T17:26:35Z","modified":"2026-08-21T19:50:34Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T18:01:36.844009Z"}],"ghsa":[{"id":"GHSA-4mhx-38g6-r4wq","title":"Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker...","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.\n\nSamly.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.\n\nThis issue affects samly: from v0.3.0 onward.","status":"published","published":"2026-08-20T18:30:59Z","modified":"2026-08-20T18:31:06Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T15:10:47.706589Z"}],"nvd":[{"id":"CVE-2026-53425","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.\n\nSamly.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.\n\nThis issue affects samly: from 0.3.0 onward.","status":"published","published":"2026-08-20T18:16:27.85Z","modified":"2026-10-26T10:10:00.14Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T14:12:40.302911Z"}],"osv":[{"id":"EEF-CVE-2026-53425","title":"Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses","description":"## Summary\n\nInsufficient 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.\n\n`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.\n\nThis issue affects samly: from 0.3.0 onward.","status":"published","published":"2026-08-20T17:26:35.537Z","modified":"2026-09-08T05:30:36.652967614Z","cvss":[{"version":"4.0","score":7.6,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-345"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}