CVE-2026-53424 exposes a critical gap in Samly's SAML 2.0 replay protection: the secure implementation path exists in the esaml dependency but is completely inaccessible to downstream developers. Esaml provides two function arities for assertion validation—a /2 variant with a no-op duplicate detector and a /3 variant accepting a custom DuplicateFun. Samly exclusively calls the insecure /2, and offers no configuration mechanism to supply the DuplicateFun, meaning SAML replay protection is permanently disabled regardless of deployment context.
This is a supply-chain failure where the secure option was available but invisible to users. A security audit of Samly's dependency tree would find esaml and conclude replay protection exists—the vulnerability lives in which arity gets called, not in missing capability. This passes superficial checks that catch most other supply-chain issues.
The blast radius of auth-layer replay vulnerabilities differs categorically from other CVEs. Compromising one SAML assertion doesn't yield one session—it potentially grants access to every session using that IdP format until the assertion's NotOnOrAfter timestamp expires. An attacker capturing a single valid assertion can reuse it against any Samly endpoint in the deployment at any time. There's no partial compromise; the vulnerability is fully exploitable for every consumer until one line of code changes.
For defenders: check your Samly version immediately. Verify whether your deployment invokes esaml's validate_assertion with the /3 arity by inspecting your dependency's call graph. If you're on an affected version, replay attacks are possible regardless of other security controls. The remediation requires Samly to wire the /3 arity with a proper DuplicateFun—there's no configuration workaround. Prioritize this if your Samly deployment processes assertions from IdPs with long session lifetimes; the exposure window compounds over time.