Listen to this Post
When a user initiates a password change via the `ChangePassword` workflow—whether through the authenticated password change endpoint, a ticket-based password reset, or the Nhost dashboard—the system correctly hashes and stores the new password using UpdateUserChangePassword. However, it fails to revoke existing sessions. The `auth.refresh_tokens` and `auth.oauth2_refresh_tokens` tables remain untouched, meaning all previously issued refresh tokens stay valid and can be used to generate new access tokens indefinitely.
This flaw exists in all password change paths, as they share the same underlying logic (handled in change_user_password.go). The attack scenario is straightforward: an attacker steals a victim’s refresh token (e.g., via XSS or a compromised device). The victim changes their password, expecting to terminate all active sessions. But because the server only updates the password hash and performs no session cleanup, the stolen token remains fully functional. The attacker retains persistent access, even after the victim’s password is changed.
The impact is severe. In credential theft scenarios, the victim’s only recovery action does nothing to stop an active session. Depending on the configured TTL, an attacker’s window of opportunity could last days or weeks. This undermines the primary purpose of password changes as a security remediation step and poses a significant risk to confidentiality and integrity.
DailyCVE Form
Platform: Nhost Auth
Version: <0.48.0
Vulnerability: Persistent session
Severity: High (8.1)
Date: 2026‑05‑08
Prediction: Patch expected within 30 days
What Undercode Say:
Check for affected refresh tokens nhost sql query "SELECT FROM auth.refresh_tokens WHERE user_id = '<victim_user_id>';" Manually revoke all refresh tokens for a user (mitigation) nhost sql query "DELETE FROM auth.refresh_tokens WHERE user_id = '<victim_user_id>';" nhost sql query "DELETE FROM auth.oauth2_refresh_tokens WHERE user_id = '<victim_user_id>';" Verify token revocation nhost sql query "SELECT count() FROM auth.refresh_tokens WHERE user_id = '<victim_user_id>';"
Exploit:
- Steal victim’s refresh token (e.g., via XSS or local access).
- Wait for victim to change password (or trigger a password reset).
- Use the stolen refresh token to generate a new access token:
curl -X POST https://auth.nhost.io/token \ -H "Content-Type: application/json" \ -d '{"refresh_token": "<stolen_token>"}' - Obtain a valid access token and continue authenticated actions.
Protection from this CVE:
- Immediate: Manually delete affected refresh tokens from the database (see above).
- Code-level: Modify `ChangePassword` workflow to delete all user sessions after a password change.
- Configuration: Set short TTL for refresh tokens (< 1 hour) to limit the window of exploitation.
- Long-term: Update Nhost to a patched version (≥0.48.0) that includes session revocation.
Impact:
- Persistent unauthorized access despite credential rotation.
- Undermines password change as a security measure.
- Enables long-term account takeover (days or weeks).
- High risk to confidentiality and integrity of user data.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
