Samly EUVD-2026-63490

The attacker must possess one genuine, cryptographically valid SAMLResponse for the victim (obtained from network capture, browser history, or logs) and must replay it before its NotOnOrAfter timestamp elapses - this bounded validity window and the need to first capture a real assertion (reflected as AT:P in the CVSS 4.0 vector) are the primary limiting factors. Beyond that there is no special product configuration required: the weakness is present in Samly's default behavior for all versions from v0.3.0 onward, and Samly provides no configuration option to enable a duplicate/replay check, so no non-default setting protects a deployment. No user interaction from the victim and no attacker authentication (PR:N) are needed to perform the replay itself.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H) rates this 9.1 (Critical), reflecting network reach, no required privileges, and high confidentiality and integrity impact from impersonating a legitimate user. The tempering signal is AT:P (Attack Requirements: Present): exploitation is not spray-and-pray because the attacker must first obtain a genuine, still-valid SAMLResponse and act within the assertion's NotOnOrAfter window, so this is realistically an adjacent/opportunistic or targeted attack (network sniffing on unterminated TLS, shared proxy/CDN logs, or browser history on a shared host) rather than mass internet-wide exploitation. No EPSS score was provided in the input, there is no public exploit identified at time of analysis, and it is not in CISA KEV - so the priority rests on the high impact and the fact that the weakness is present in default configurations with no in-product mitigation, not on evidence of active exploitation. Any operator running Samly for SSO should treat it as high priority given that a captured assertion yields full account takeover, but the practical exposure depends heavily on where SAMLResponses can leak in a given deployment.

An attacker captures a valid SAMLResponse for a target user - for example by observing it on a shared network path, pulling it from reverse-proxy or application logs, or reading it from browser history on a shared workstation. Before the assertion's NotOnOrAfter timestamp passes, the attacker POSTs the identical bytes to the application's Samly consume/ACS endpoint, and because the duplicate detector is a no-op the app establishes an authenticated session as that user, repeatable until expiry. No public proof-of-concept is identified at time of analysis, but the technique requires only replaying captured bytes.