GHSA-7hgr-xvrr-xpw3

Description

When a user changes their password, either through the authenticated password change endpoint or a password reset ticket, the ChangePassword workflow correctly hashes and persists the new password via UpdateUserChangePassword. However, it does not revoke existing sessions. The auth.refresh_tokens and auth.oauth2_refresh_tokens tables are left untouched, meaning all previously issued refresh tokens remain valid and can continue generating new access tokens indefinitely.

This vulnerability affects all password change paths (handled in change_user_password.go), since they share the same underlying workflow:

• Authenticated password change via the Nhost dashboard or client SDK
• Ticket-based password reset (magic links / recovery flows)
• OAuth2/OIDC sessions managed via auth.oauth2_refresh_tokens

Attack Scenario

1. An attacker steals a victim's refresh token via XSS or a compromised device.
2. The victim changes their password, expecting it to terminate all active sessions.
3. The server updates password_hash but performs no session cleanup, the stolen token remains fully functional.

Impact

The attacker retains persistent access even after the victim's password change. This is especially severe in credential theft scenarios, where the victim's only recovery action does nothing against an active session. Depending on configured TTL, the attacker's window could be days or weeks.

Description

When a user changes their password, either through the authenticated password change endpoint or a password reset ticket, the ChangePassword workflow correctly hashes and persists the new password via UpdateUserChangePassword. However, it does not revoke existing sessions. The auth.refresh_tokens and auth.oauth2_refresh_tokens tables are left untouched, meaning all previously issued refresh tokens remain valid and can continue generating new access tokens indefinitely.

This vulnerability affects all password change paths (handled in change_user_password.go), since they share the same underlying workflow:

• Authenticated password change via the Nhost dashboard or client SDK
• Ticket-based password reset (magic links / recovery flows)
• OAuth2/OIDC sessions managed via auth.oauth2_refresh_tokens

Attack Scenario

1. An attacker steals a victim's refresh token via XSS or a compromised device.
2. The victim changes their password, expecting it to terminate all active sessions.
3. The server updates password_hash but performs no session cleanup, the stolen token remains fully functional.

Impact

The attacker retains persistent access even after the victim's password change. This is especially severe in credential theft scenarios, where the victim's only recovery action does nothing against an active session. Depending on configured TTL, the attacker's window could be days or weeks.

nhost has Session Persistence After Password Change in github.com/nhost/nhost