CVE-2026-53424: Missing one-time-use enforcement in Samly allows replay of SAML bearer assertions
Authentication Bypass by Capture-replay vulnerability in dropbox samly allows an attacker to authenticate as the subject of a captured SAML assertion by resubmitting it.
Samly.Helper.decodeidpauthresp/3 in lib/samly/helper.ex calls esamlsp:validateassertion/2, whose default duplicate detector is a no-op. The /3 arity accepting a DuplicateFun exists in esaml and implements the check, but Samly never calls it and offers no configuration to supply one, so the SAML 2.0 Web Browser SSO Profile requirement that a bearer assertion be used once is unenforced. An attacker holding a valid SAMLResponse obtained from the network, from browser history, or from logs can submit the identical bytes repeatedly until the assertion's NotOnOrAfter passes, each time establishing a session as the assertion's subject.
This issue affects samly: from v0.3.0 onward.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Implement one-time-use (duplicate) enforcement for SAML bearer assertions instead of using the default no-op duplicate detector in esaml_sp:validate_assertion/2; ensure the DuplicateFun variant that performs the duplicate check is actually invoked for Samly.
Event History
Frequently Asked Questions
Which Samly versions are affected?
Samly is affected from version 0.3.0 onward.
Is a non-default configuration required for exploitation?
No. Samly calls the esaml assertion validation function whose default duplicate detector is a no-op, and Samly provides no configuration for supplying a duplicate-check function.
What does an attacker need to replay an authentication?
The attacker needs a valid SAMLResponse for the target subject. The response could be obtained from the network, browser history, or logs.
How long can a captured response be replayed?
The same SAMLResponse can be resubmitted repeatedly until the assertion's NotOnOrAfter time passes.