Answer in brief
CVE-2026-53425 records a High severity (CVSS 7.6) vulnerability in Missing InResponseTo validation in Samly allows acceptance of unsolicited SAML responses. The current sources do not mark it as known exploited. The current feed maps dropbox/dropbox/samly (generic), handnot2/handnot2/samly (generic), dropbox/samly (generic), handnot2/samly (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.6. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps dropbox/dropbox/samly (generic), handnot2/handnot2/samly (generic), dropbox/samly (generic), handnot2/samly (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| dropbox/dropbox/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| handnot2/handnot2/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| dropbox/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| handnot2/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| dropbox/samlygeneric | >=0.3.0 <* | * |
| dropbox/samlygeneric | >=v0.3.0 <* | * |
Published upstream
Aug 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 24, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 20, 2026
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.
Quoted source text, attributed separately from HOL analysis.