Answer in brief
CVE-2026-53425 records a Unknown severity 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/samly (generic), dropbox/samly (generic), handnot2/samly (generic), dropbox/samly (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. 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/samly (generic), dropbox/samly (generic), handnot2/samly (generic), dropbox/samly (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| dropbox/samlygeneric | >=v0.3.0 <* | * |
| dropbox/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| handnot2/samlygeneric | >=8a5bb1b4a4753d05470da2036323477f63cfdf4c <* | * |
| dropbox/samlygeneric | >=0.3.0 <* | * |
Published upstream
Aug 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 20, 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.