samly CVE-2026-53425

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.

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.

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.