Imagine walking into a high-security office building. At the front desk, you present two forms of ID, pass a biometric scan, and receive a visitor badge. From that moment on, nobody asks for your identification again. You simply flash the badge, and every door opens. Now imagine someone steals that badge. They don’t need your ID. They don’t need to answer security questions. They just walk through the same doors you would, unquestioned.
This is exactly how session token theft works—and why a password reset often fails to stop it. The badge, in this analogy, is your session token: a digital credential issued by a web application after you successfully authenticate. Once issued, the application treats that token as proof of identity. Who holds the token is, for all practical purposes, the authorized user. Changing your password updates the record at the front desk, but it doesn’t automatically confiscate every badge already in circulation. That disconnect is what attackers exploit.
According to Verizon’s 2025 Data Breach Investigations Report, 88% of breaches involved stolen credentials, and increasingly those credentials aren’t passwords, they’re tokens. The problem isn’t new, but it has become far more common as attackers shift from stealing passwords to hijacking active sessions. A password reset that doesn’t also invalidate every existing session is like changing the locks on your front door while leaving the back door wide open.
The Mechanics of Session Token Theft
A session token is a bearer credential. In security architecture, “bearer” means exactly what it sounds like: whoever bears the token gets access. The server does not re-verify the user’s identity with each request. It checks the token, confirms it hasn’t expired, and grants entry. This design keeps the web usable (without it, you’d need to re-authenticate with every page load) but it also creates a fundamental vulnerability.
Attackers steal session tokens through several well-established methods. Infostealer malware is the most prevalent vector today. Commodity malware families like RedLine, Raccoon, and LummaC2 silently extract browser cookies, saved credentials, and active session tokens from infected machines, often within minutes of infection. Threat intelligence firm Flashpoint estimated that 5.8 million hosts were infected by infostealers during the first half of 2025 alone, harvesting over 1.8 billion credentials. Those stolen tokens are then packaged and sold on dark web marketplaces, where buyers can browse available sessions as casually as they would an online product listing.
The second major vector is adversary-in-the-middle (AitM) phishing. Tools like Evilginx act as transparent proxies, sitting between the victim and the legitimate login page. When the user authenticates (completing MFA and all) the proxy captures the session token in real time. The attacker never sees the password, but they don’t need to. They have something better: a fully authenticated session they can replay from their own browser.
Cross-site scripting (XSS) and session fixation round out the common attack patterns. In an XSS attack, malicious scripts injected into a vulnerable site can read session cookies directly from the victim’s browser. Session fixation tricks a user into authenticating with a session ID the attacker already knows, eliminating the need to steal anything at all.
Why Password Resets Fail Against Session Token Theft
The core issue is architectural. Authentication and session management are two separate subsystems. When you reset your password, the authentication system updates its record: the old hash is replaced, and future login attempts require the new credential. The session management system, however, has no idea this happened. It’s still holding a collection of valid tokens, each one representing a previously authenticated session, and it will continue to honor them until they expire or are explicitly revoked.
This isn’t hypothetical. The OWASP Application Security Verification Standard explicitly calls for applications to “terminate all other active sessions after a successful password change”. Yet security researchers routinely find this step missing in production systems. A recent security audit of one open-source project found that after a password reset, “existing sessions are NOT invalidated. An attacker with a stolen refresh token can continue using the account even after the user changes their password”. This pattern repeats across codebases large and small.
Refresh tokens make the problem worse. Unlike short-lived access tokens, refresh tokens can live for days, weeks, or even months. They’re designed to silently obtain new access tokens without user interaction. If an attacker steals a refresh token, they can maintain persistent access long after a password reset—generating new access tokens on demand while the legitimate user believes the threat is gone. As LoginRadius notes in its analysis of refresh token rotation, “when a refresh token is stolen, nothing breaks. The system continues to function as designed.”
Auth0’s own documentation confirms the gap: after a password reset, “the user will continue to be able to get new access tokens, given the current refresh token is still valid”. The token has to expire naturally or be revoked through a separate API call, something most applications never implement. Ping Identity similarly acknowledges that unless the password reset process explicitly revokes tokens, “the user would generally be allowed to get a new token, yes”.
The Real-World Cost of Overlooking Session Token Theft
The CircleCI breach of early 2023 remains one of the clearest illustrations of this attack pattern. An attacker installed malware on a CircleCI employee’s laptop (malware that went undetected by the company’s antivirus software), and stole session tokens backed by MFA. Those tokens allowed the attacker to impersonate the employee from a remote location, escalate access to production systems, and ultimately compromise customer GitHub tokens.
Salesforce and Air France customers learned a similar lesson in 2025. According to a federal lawsuit filed in the Northern District of California, attackers exploited OAuth tokens and phishing applications to compromise Salesforce systems, exposing sensitive data, including names, dates of birth, and Social Security numbers, belonging to more than one million individuals. The complaint describes a hub-and-spoke model where a failure at the central platform rippled outward to every connected organization.
Slack’s 2022 incident, where stolen employee tokens provided access to private GitHub repositories, further demonstrated that developer tokens can become keys to some of an organization’s most sensitive environments. Across all of these cases, password resets alone would have been meaningless. The attackers weren’t using passwords. They were using tokens that had already been issued to legitimate, MFA-verified sessions.
Building a Defense That Survives Session Token Theft
Protecting against token theft requires thinking beyond the login page. Several layers of defense can dramatically reduce the blast radius of a stolen token.
Invalidate Sessions on Password Reset
The single most effective countermeasure is also the most straightforward: when a user changes their password, destroy every active session associated with that account. OWASP’s guidance is unambiguous on this point. The application should “properly invalidate all user sessions server-side on password reset”. This includes refresh tokens, OAuth grants, and any API tokens that might have been issued. Several identity platforms now offer post-change password actions that can trigger token revocation programmatically.
Shorten Token Lifetimes
A stolen token is only dangerous for as long as it remains valid. Reducing session lifetimes (access tokens measured in minutes rather than hours, refresh tokens measured in hours rather than weeks) shrinks the window of opportunity. As Obsidian Security’s analysis of token attacks explains, “access tokens grant temporary access to specific resources. These short-lived credentials typically expire within minutes to hours, limiting the window of opportunity for attackers”. Combined with refresh token rotation that detects reuse, short lifetimes turn a stolen token from a persistent backdoor into a quickly-closing window.
Deploy Continuous Access Evaluation
Microsoft’s Continuous Access Evaluation (CAE) represents a shift toward real-time session validation. Rather than relying solely on token expiration, CAE continuously evaluates session validity against policy changes, user risk signals, and critical security events. When a user’s password is changed or an account is disabled, CAE revokes access tokens and refresh tokens in near real time. This effectively closes the gap between a password reset and session termination.
Bind Tokens to Devices
Token binding cryptographically ties a session token to the specific device that requested it. Approaches like mTLS and DPoP (Demonstration of Proof-of-Possession) embed proof of possession into the token itself. If an attacker steals the token and tries to replay it from a different machine, the cryptographic binding fails and the request is rejected. Implementation remains limited, but the approach addresses the bearer token problem at its root: a stolen token becomes worthless outside its original context.
Monitor for Behavioral Anomalies
Because stolen tokens are used differently than legitimate sessions—different IP addresses, different User-Agent strings, different geographic locations—behavioral monitoring can surface token theft that technical controls miss. Sudden IP address changes, impossible travel patterns, and unusual data access volumes are all signals that a session may have been hijacked. Detection alone isn’t defense, but it creates the opportunity to revoke tokens before damage escalates.
Fixing the Disconnect
Session token theft exposes a structural flaw in how most web applications handle identity: authentication and session management operate in separate silos, and a password reset doesn’t automatically bridge them. The fix is not to abandon sessions, they’re essential to a usable web, but to treat them as the high-value credentials they actually are.
For developers, this means pairing every password reset with explicit session revocation. For identity providers, it means building continuous evaluation and token binding into the default configuration rather than offering them as optional add-ons. And for anyone responsible for securing an application or service, it means recognizing that a password change that leaves sessions intact offers only the illusion of security. The attacker isn’t using your password. They’re using your badge. Take the badge back.
