{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-53425", "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "state": "PUBLISHED", "assignerShortName": "EEF", "dateReserved": "2026-06-09T11:01:47.529Z", "datePublished": "2026-08-20T17:26:35.537Z", "dateUpdated": "2026-08-20T18:38:13.727Z"}, "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\u00e4nnchen / 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": {"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "shortName": "EEF", "dateUpdated": "2026-08-20T18:38:13.727Z"}, "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"}}}

{}

{"affected": [{"affectedData": [{"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": "v0.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"}]}], "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"}], "cveTags": [], "descriptions": [{"lang": "en", "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 v0.3.0 onward."}], "id": "CVE-2026-53425", "lastModified": "2026-08-20T18:16:27.850", "metrics": {"cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 7.6, "baseSeverity": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "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/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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "type": "Secondary"}]}, "published": "2026-08-20T18:16:27.850", "references": [{"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://cna.erlef.org/cves/CVE-2026-53425.html"}, {"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "url": "https://osv.dev/vulnerability/EEF-CVE-2026-53425"}], "sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-345"}], "source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db", "type": "Secondary"}]}

{}

{}