Token replay against an unbound endpoint

How it works

Most authentication tokens, session cookies, SAML assertions, OAuth access tokens, WebAuthn challenges, are bearer credentials at the protocol level unless something explicitly binds them. A bound token is tied to the specific client, device, or session that requested it, so a copy presented from anywhere else is rejected. An unbound token carries no such link: any party holding a valid copy is accepted exactly as if they were the original requester, regardless of where the request comes from.

Token replay against an unbound endpoint means an attacker obtains a valid token through any means, a buffer over-read that leaks memory, a stolen HAR file, a copied cookie, or a challenge issued on one host and never checked against the host that completes it, and simply presents that token to the endpoint again. Citrix Bleed (CVE-2023-4966) is the clearest public example: a buffer over-read on NetScaler ADC and Gateway returned memory containing live session cookies to an unauthenticated caller, who replayed them and was authenticated with no password and no MFA check, because the session already existed and the endpoint accepted the cookie with no additional binding verification. The same failure pattern showed up again in 2026 research on Entra ID's WebAuthn challenges, which are not bound to the session, user, or tenant that requested them, so a challenge obtained on one host can be signed and replayed from a different one entirely.

Why it works

Strengthening the credential does nothing if the endpoint that accepts it never checks whether the presenter is the party who obtained it. Passkeys, hardware keys, and short-lived tokens all raise the bar for stealing a credential in the first place, but none of that matters if the verification step at the other end is "is this a valid token" rather than "is this a valid token presented by the party it was issued to." Binding is the property that closes that gap, and it is frequently the piece left out, either because the protocol did not require it, the implementation skipped it for convenience, or a bug like Citrix Bleed exposed tokens through a path the binding check never anticipated.

How to detect it

• Session or token use with no matching interactive authentication event for that session, particularly from a new IP or ASN.
• Authentication artifacts (WebAuthn assertions, session cookies) used from a device or client different from the one that originally requested them, where correlation data exists.
• A spike in successful authentications from previously unseen sources immediately following disclosure of a token-leaking vulnerability in an internet-facing appliance.

Be honest about the limits: legitimate token use from a new device happens constantly through browser sync, password managers, and multi-device workflows, so an unbound token used from an unfamiliar source is not proof of replay on its own. The strongest signal is the complete absence of a corresponding interactive login event, which legitimate multi-device use should still produce somewhere in the chain.

How to stop it

• Bind tokens and sessions to a device or client using DPoP or mutual TLS, so a replayed token fails everywhere except its origin.
• Bind challenges to the session, user, and tenant that requested them, closing the specific gap that let a WebAuthn challenge be signed on a different host than the one that asked for it.
• Patch internet-facing appliances promptly and, when a token-leak vulnerability like Citrix Bleed is disclosed, terminate all existing sessions rather than assuming a patch alone is sufficient; a patched system with live leaked tokens is still compromised.
• Shorten token and session lifetimes to reduce the window in which a leaked or replayed token remains useful.
• Hunt for sessions with no matching login event as a standing detection rule, not just a one-time response to a disclosed vulnerability.

Seen in the wild

• Three passkey attacks land in one week, none of them breaking the cryptography
• CVE-2023-4966: Citrix Bleed, session-token leak from NetScaler ADC

Sources

• MITRE ATT&CK T1550.004: Use Alternate Authentication Material: Web Session Cookie
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)