{"affected":[{"package":{"ecosystem":"Hex","name":"samly","purl":"pkg:hex/samly"},"ranges":[{"events":[{"introduced":"0.3.0"}],"type":"SEMVER"}],"versions":["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","0.10.0","0.10.1","1.0.0-rc.0","1.0.0-rc.1","1.0.0","1.1.0","1.2.0","1.3.0","1.4.0"]},{"ranges":[{"events":[{"introduced":"8a5bb1b4a4753d05470da2036323477f63cfdf4c"}],"repo":"https://github.com/dropbox/samly","type":"GIT"}]},{"ranges":[{"events":[{"introduced":"8a5bb1b4a4753d05470da2036323477f63cfdf4c"}],"repo":"https://github.com/handnot2/samly","type":"GIT"}]}],"aliases":["CVE-2026-53425"],"credits":[{"name":"Mark Madsen","type":"REPORTER"},{"name":"Jonatan Männchen / EEF","type":"COORDINATOR"}],"database_specific":{"capec_ids":["CAPEC-62"],"cpe_ids":["cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*","cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*"],"cwe_ids":["CWE-345"]},"details":"## 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\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.","id":"EEF-CVE-2026-53425","modified":"2026-08-20T18:38:14.248555Z","published":"2026-08-20T17:26:35.537Z","references":[{"type":"WEB","url":"https://cna.erlef.org/cves/CVE-2026-53425.html"},{"type":"PACKAGE","url":"https://hex.pm/packages/samly"}],"related":[],"schema_version":"1.7.3","severity":[{"score":"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","type":"CVSS_V4"}],"summary":"Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses","upstream":[]}