{"containers":{"cna":{"affected":[{"collectionURL":"https://repo.hex.pm","cpes":["cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.Samly.SPHandler'"],"packageName":"samly","packageURL":"pkg:hex/samly","product":"samly","programFiles":["lib/samly/sp_handler.ex"],"programRoutines":[{"name":"'Elixir.Samly.SPHandler':consume_signin_response/1"}],"repo":"https://github.com/dropbox/samly","vendor":"dropbox","versions":[{"lessThan":"*","status":"affected","version":"0.3.0","versionType":"semver"}]},{"collectionURL":"https://github.com","cpes":["cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.Samly.SPHandler'"],"packageName":"dropbox/samly","packageURL":"pkg:github/dropbox/samly","product":"samly","programFiles":["lib/samly/sp_handler.ex"],"programRoutines":[{"name":"'Elixir.Samly.SPHandler':consume_signin_response/1"}],"repo":"https://github.com/dropbox/samly","vendor":"dropbox","versions":[{"lessThan":"*","status":"affected","version":"8a5bb1b4a4753d05470da2036323477f63cfdf4c","versionType":"git"}]},{"collectionURL":"https://github.com","cpes":["cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.Samly.SPHandler'"],"packageName":"handnot2/samly","packageURL":"pkg:github/handnot2/samly","product":"samly","programFiles":["lib/samly/sp_handler.ex"],"programRoutines":[{"name":"'Elixir.Samly.SPHandler':consume_signin_response/1"}],"repo":"https://github.com/handnot2/samly","vendor":"handnot2","versions":[{"lessThan":"*","status":"affected","version":"8a5bb1b4a4753d05470da2036323477f63cfdf4c","versionType":"git"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*","versionStartIncluding":"0.3.0","vulnerable":true},{"criteria":"cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*","versionStartIncluding":"0.3.0","vulnerable":true}],"negate":false,"operator":"OR"}],"operator":"AND"}],"credits":[{"lang":"en","type":"reporter","value":"Mark Madsen"},{"lang":"en","type":"coordinator","value":"Jonatan Männchen / EEF"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>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.</p>\n<p><code>Samly.SPHandler.validate_authresp/3</code> in <code>lib/samly/sp_handler.ex</code> validates a SAML response for the SP-initiated flow by comparing only the <code>RelayState</code> value, the IdP identifier, and the presence of a target URL held in the session. It never compares <code>SubjectConfirmationData/@InResponseTo</code> against the ID of the <code>AuthnRequest</code> 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 <code>InResponseTo</code> does not match a request it made. The underlying <code>esaml</code> library checks status, signature, recipient, audience, and staleness, but likewise never inspects <code>InResponseTo</code>, 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 <code>RelayState</code> matching the victim's session; the assertion signature itself remains intact, so this is not a signature-forgery issue.</p>\n<p>This issue affects samly: from 0.3.0 onward.</p>"},{"base64":false,"type":"text/markdown","value":"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\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."}],"value":"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."}],"impacts":[{"capecId":"CAPEC-62","descriptions":[{"lang":"en","value":"CAPEC-62 Cross Site Request Forgery"}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":7.6,"baseSeverity":"HIGH","privilegesRequired":"NONE","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"PASSIVE","valueDensity":"NOT_DEFINED","vectorString":"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","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-345","description":"CWE-345 Insufficient Verification of Data Authenticity","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-08-20T18:38:13.727Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"tags":["related","third-party-advisory"],"url":"https://cna.erlef.org/cves/CVE-2026-53425.html"},{"tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-53425"}],"source":{"discovery":"UNKNOWN"},"title":"Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses"}},"cveMetadata":{"assignerOrgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","assignerShortName":"EEF","cveId":"CVE-2026-53425","datePublished":"2026-08-20T17:26:35.537Z","dateReserved":"2026-06-09T11:01:47.529Z","dateUpdated":"2026-08-20T18:38:13.727Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"}