CVE-2026-53425: CWE-345 Insufficient Verification of Data Authenticity in dropbox samly
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.
AI Analysis
Technical Summary
The vulnerability in Dropbox samly (version 0.3.0) stems from the SPHandler.validate_authresp/3 function failing to validate the SubjectConfirmationData/@InResponseTo attribute in SAML responses. The function only compares RelayState, IdP identifier, and presence of a target URL but does not check that the InResponseTo matches the AuthnRequest ID issued by the service provider, which is never persisted. According to SAML 2.0 Core section 4.1.4.3, a service provider must reject responses whose InResponseTo does not correspond to a request it made. The underlying esaml library also does not inspect InResponseTo, leaving this verification gap open. An attacker with a valid signed assertion from the trusted IdP for their own account and a RelayState matching the victim's session can exploit this to establish an authenticated session without a legitimate request. This is a logic flaw in the SAML response validation process, not a cryptographic signature issue.
Potential Impact
An attacker can establish an authenticated session with the service provider by replaying or injecting a valid SAML response that was never requested by the service provider. This can lead to unauthorized access to the victim's session or resources. The vulnerability requires the attacker to have a valid signed assertion from the trusted IdP for their own account and to match the victim's RelayState, but it bypasses the critical check that the response corresponds to an actual authentication request. This undermines the integrity of the SAML authentication flow and can result in session hijacking or unauthorized access.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users of samly version 0.3.0 should consider implementing additional validation to ensure the InResponseTo attribute in SAML responses matches the ID of the AuthnRequest issued by the service provider. Monitoring for suspicious SAML responses and restricting RelayState values may help reduce risk, but these are partial mitigations. Follow official vendor advisories for updates and patches.
CVE-2026-53425: CWE-345 Insufficient Verification of Data Authenticity in dropbox samly
Description
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.
CVSS v4.0
Score 7.6high
Affected software
cpe:2.3:a:dropbox:samly:*:*:*:*:*:*:*:*cpe:2.3:a:handnot2:samly:*:*:*:*:*:*:*:*Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Dropbox samly (version 0.3.0) stems from the SPHandler.validate_authresp/3 function failing to validate the SubjectConfirmationData/@InResponseTo attribute in SAML responses. The function only compares RelayState, IdP identifier, and presence of a target URL but does not check that the InResponseTo matches the AuthnRequest ID issued by the service provider, which is never persisted. According to SAML 2.0 Core section 4.1.4.3, a service provider must reject responses whose InResponseTo does not correspond to a request it made. The underlying esaml library also does not inspect InResponseTo, leaving this verification gap open. An attacker with a valid signed assertion from the trusted IdP for their own account and a RelayState matching the victim's session can exploit this to establish an authenticated session without a legitimate request. This is a logic flaw in the SAML response validation process, not a cryptographic signature issue.
Potential Impact
An attacker can establish an authenticated session with the service provider by replaying or injecting a valid SAML response that was never requested by the service provider. This can lead to unauthorized access to the victim's session or resources. The vulnerability requires the attacker to have a valid signed assertion from the trusted IdP for their own account and to match the victim's RelayState, but it bypasses the critical check that the response corresponds to an actual authentication request. This undermines the integrity of the SAML authentication flow and can result in session hijacking or unauthorized access.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users of samly version 0.3.0 should consider implementing additional validation to ensure the InResponseTo attribute in SAML responses matches the ID of the AuthnRequest issued by the service provider. Monitoring for suspicious SAML responses and restricting RelayState values may help reduce risk, but these are partial mitigations. Follow official vendor advisories for updates and patches.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-06-09T11:01:47.529Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a873babacd9273b49eebb02
Added to database: 08/20/2026, 17:38:51 UTC
Last enriched: 08/20/2026, 17:52:10 UTC
Last updated: 08/21/2026, 00:25:12 UTC
Views: 10
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.