No Session Invalidation on Password Change
Active sessions remain valid after a user changes their password, leaving attackers who already compromised a session with continued access even after the user takes remediation action.
How It Works
When a user notices unusual activity and changes their password, they expect to kick out any active attackers. If existing sessions aren't invalidated on password change, an attacker's stolen session token continues to work. The user did the right thing — your code let the attacker stay.
// BAD: password change doesn't invalidate sessions
async function changePassword(userId: string, newPassword: string) {
const hash = await bcrypt.hash(newPassword, 12);
await db.users.update({ where: { id: userId }, data: { passwordHash: hash } });
// All existing sessions still valid — attacker stays in
}// GOOD: invalidate all sessions on password change
async function changePassword(userId: string, newPassword: string) {
const hash = await bcrypt.hash(newPassword, 12);
// Rotate a secret version token stored with the user
const sessionVersion = crypto.randomUUID();
await db.users.update({
where: { id: userId },
data: { passwordHash: hash, sessionVersion }
});
// Tokens issued before this version are now invalid
}Real-World Example
When users report 'I changed my password but my account was still being accessed', this is usually the cause. Attackers who establish persistent access rely on this gap. It's also a compliance issue under many security frameworks.
How to Prevent It
- Store a sessionVersion field on the user and include it in JWT claims
- On password change, rotate the sessionVersion — older tokens with the old version are rejected
- Alternatively, invalidate all sessions stored in your session store for that user
- Send the user an email notification when their password is changed from a new device/location
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Session Fixation
highThe server reuses the same session ID before and after login, allowing an attacker who planted a known session ID to hijack the authenticated session.
No Account Lockout / Brute Force Protection
mediumLogin endpoints with no rate limiting or lockout mechanism, allowing attackers to try unlimited username and password combinations until they find valid credentials.
Weak Password Policy
mediumNo minimum length, complexity, or common-password requirements on registration or password change, making user accounts easily brute-forced or guessed.
OAuth State Parameter Missing
highOAuth authorization flow implemented without a random `state` parameter, allowing CSRF attacks that link a victim's account to the attacker's OAuth identity.