Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
9.1
CVE-2026-53424: Samly allows reuse of captured login token
CVE-2026-53424 · published 1 month ago
Summary
The Samly component does not check that a SAML login token is used only once. An attacker who obtains a valid token can replay it to log in as the original user until the token expires. Update Samly to a version that enforces one‑time use or add a duplicate‑use check to stop replay attacks.
What to do
- Update dropbox samly to version * or later.
- Update handnot2 samly to version * or later.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| – | dropbox | samly | < * |
| – | handnot2 | samly | < * |
| Hex | handnot2 | samly | >= 0.3.0 |
Original advisory text
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.decode_idp_au...
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.decode_idp_auth_resp/3 in lib/samly/helper.ex calls esaml_sp:validate_assertion/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 0.3.0 onward.
Samly.Helper.decode_idp_auth_resp/3 in lib/samly/helper.ex calls esaml_sp:validate_assertion/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 0.3.0 onward.
References
- https://cna.erlef.org/cves/CVE-2026-53424.html related third-party-advisory
- https://osv.dev/vulnerability/EEF-CVE-2026-53424 related
- https://hex.pm/packages/samly Product
Severity
9.1
Critical
Exploitation
EPSS <1%
Type
CWE-294Authentication Bypass by Capture-replay
Timeline
Published20 Aug 2026
Updated27 Sep 2026
First seen20 Aug 2026
Track software like this
Free during beta