Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to trusted IdP with own account
-
DeliveryCapture validly signed SAML assertion
-
ExploitObtain or predict victim's RelayState from active SP session
-
ExecutionSubmit assertion with victim's RelayState to ACS endpoint
-
Persistsamly validates RelayState and IdP identity only
-
ImpactSP establishes authenticated session bypassing InResponseTo check
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | Three concrete prerequisites must be satisfied: (1) the attacker must hold a valid account at the IdP trusted by the target samly SP, enabling them to obtain a legitimately IdP-signed SAML assertion - assertion signature forgery is not involved and forged assertions are rejected by esaml; (2) the attacker must know or derive a RelayState value that matches an active or recent session entry in the SP's session store, which depends on RelayState predictability or the ability to observe the victim's browser traffic; (3) the target application must be running samly v0.3.0 or later and have SP-initiated SAML SSO enabled. Unauthenticated parties with no IdP account cannot exploit this vulnerability. The attack does not apply where RelayState values are cryptographically random and unguessable. The CVSS 4.0 AT:P metric reflects these attack requirements accurately. |
| Impact | The CVSS 4.0 score of 7.6 (AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N) correctly reflects high confidentiality and integrity impact tempered by real prerequisites captured in AT:P and UI:P. The dominant limiting factor is that exploitation requires a legitimately signed SAML assertion from the trusted IdP - the attacker must have an account at that IdP and cannot forge signatures. Additionally, the attacker must obtain a RelayState value from the victim's active session, which requires either network-level observation, RelayState predictability, or social engineering. These barriers make this a targeted rather than opportunistic attack. No EPSS data is available; the vulnerability carries no CISA KEV listing and no known public exploit. Real-world risk is meaningful in enterprise SSO environments - the confidentiality and integrity impact of session hijacking in a business application is significant - but mass exploitation is constrained by the IdP credential and RelayState requirements. The 'Denial of Service' tag in the source data does not correspond to any described DoS mechanism and is likely a tagging artifact. |
| Exploit ScenarioDerived | An attacker with a legitimate account at the IdP trusted by the samly-backed SP authenticates to the IdP and retains the resulting validly signed SAML assertion for their own account. Through network observation, prediction, or social engineering they obtain a RelayState value tied to a victim's active SP-initiated login flow. They submit the assertion with the victim's RelayState to the SP's ACS endpoint; samly validates RelayState, IdP identity, and target URL presence, finds all checks pass, and establishes an authenticated session - without the SP ever having requested that assertion or bound it to that session. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 20, 2026
Authentication bypass in the Elixir SAML library samly (v0.3.0+) allows an attacker holding a validly IdP-signed SAML assertion to establish an authenticated session on the service provider without the SP ever having issued the corresponding AuthnRequest. The root cause is that Samly.SPHandler.validate_authresp/3 never persists the AuthnRequest ID and therefore cannot compare it against the SubjectConfirmationData/@InResponseTo attribute in incoming responses, violating SAML 2.0 Core §4.1.4.3. No public exploit has been identified at time of analysis, but the attack is technically accessible to any party who holds a legitimately signed IdP assertion and can obtain a victim's RelayState value.
RemediationAI
The definitive fix requires samly to persist the AuthnRequest ID at the time the SP-initiated flow begins and compare it against the InResponseTo attribute of the incoming SAML response, rejecting any response where no match is found - as mandated by SAML 2.0 Core §4.1.4.3. No specific patched release version is confirmed in the available data; consumers should monitor the ERLEF CNA advisory at https://cna.erlef.org/cves/CVE-2026-53425.html and the OSV entry at https://osv.dev/vulnerability/EEF-CVE-2026-53425 for patch availability. As an immediate compensating control, if the application does not require IdP-initiated SSO, operators should restrict the ACS endpoint to only process assertions when a freshly generated AuthnRequest is present in the server-side session, enforced at the application layer rather than relying on samly. Using unpredictable, cryptographically random RelayState values reduces the probability of an attacker successfully correlating the RelayState to a victim's session, though it does not close the underlying flaw.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
samly is an Elixir SAML 2.0 service provider library (CPE: cpe:2.3:a:dropbox:samly and cpe:2.3:a:handnot2:samly) built atop the esaml Erlang library for use in Phoenix Framework applications. The vulnerable function Samly.SPHandler.validate_authresp/3 (lib/samly/sp_handler.ex) validates SP-initiated authentication responses by checking only three values: the RelayState, the IdP identifier, and whether a target URL exists in the session. SAML 2.0 Core §4.1.4.3 explicitly requires an SP to compare the InResponseTo attribute of SubjectConfirmationData against the ID of an AuthnRequest it actually issued, and to reject responses where no match is found. Because samly never persists the AuthnRequest ID, this comparison is structurally impossible. The underlying esaml library validates assertion signature, recipient, audience, and staleness, but also skips InResponseTo inspection, meaning no layer of the stack compensates for the gap. CWE-345 (Insufficient Verification of Data Authenticity) applies: the SP cannot confirm that the assertion corresponds to a request it originated.
Know when Dropbox gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
AC:H because attacker needs a valid IdP-signed assertion plus victim's RelayState; UI:R because victim's active session state is a prerequisite; S:C because exploiting the SAML auth component crosses into the broader application session.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
DescriptionCVE.org
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 v0.3.0 onward.
Executive ViewAI
Samly SAML library (v0.3.0 and later) contains an authentication bypass vulnerability affecting services relying on it for identity management. Attackers possessing legitimately signed SAML assertions can establish unauthorized authenticated sessions without proper authorization validation, potentially compromising access controls across affected applications.
No vendor-released patch identified at time of analysis. Interim mitigations: implement enhanced logging of SAML authentication flows including RelayState tracking and assertion origin verification; restrict identity provider trust relationships to pre-approved providers; establish monitoring for suspicious authentication patterns; prepare and test upgrade path for deployment immediately upon patch availability.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Dropbox Lepton v1.2.1-185-g2a08b77 was discovered to contain a heap-buffer-overflow in the function aligned_dealloc():sr
Dropbox.exe (and QtWebEngineProcess.exe in the Web Helper) in the Dropbox desktop application 71.4.108.0 store cleartext
In the Samly package before 1.4.0 for Elixir, Samly.State.Store.get_assertion/3 can return an expired session, which int
A vulnerability was found in Dropbox merou. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitab
The allocate_channel_framebuffer function in uncompressed_components.hh in Dropbox Lepton 1.2.1 allows remote attackers
An issue was discovered in Dropbox Lepton 1.2.1. Rated medium severity (CVSS 5.5), this vulnerability is no authenticati
Authentication bypass via SAML assertion replay affects Samly, the Elixir/Plug SAML 2.0 Service Provider library from Dr
Dropbox Desktop Folder Sharing Mark-of-the-Web Bypass Vulnerability. Rated high severity (CVSS 8.8), this vulnerability
Unauthenticated memory exhaustion in the Erlang esaml SAML library (version 0.1.0 and later) lets a remote attacker cras
Unauthenticated remote denial of service in the Erlang SAML library esaml (0.1.0 and later) allows an attacker to abort
Dropbox SDK for Android before 1.6.2 might allow remote attackers to obtain sensitive information via crafted malware or
An issue was discovered in the com.getdropbox.Dropbox app 100.2 for iOS. Rated medium severity (CVSS 6.4), this vulnerab
EUVD-2026-63489
GHSA-4mhx-38g6-r4wq
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB