NocoDB: Refresh Tokens Persist Through Password Recovery
Description
Summary
A stolen refresh token survived a password-forgot flow and could be used to mint fresh JWTs even after the user reset their password.
Details
passwordChange and passwordReset deleted the user's refresh tokens, but passwordForgot only rotated token_version and revoked OAuth tokens — it did not call UserRefreshToken.deleteAllUserToken(user.id). An attacker holding a captured refresh cookie could still exchange it for a new access token after the victim triggered the recovery flow.
Impact
Persistent unauthorized access after password recovery. Once a refresh token leaks, the documented "Forgot password" recovery flow did not in fact revoke the attacker's session.
Credit
This issue was reported by @bugbunny-research.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"The `passwordForgot` handler omitted the call to delete the user's refresh tokens, so a previously stolen refresh token remained valid after password recovery."
Attack vector
An attacker who has captured a victim's refresh token (e.g., via XSS, network interception, or a compromised device) can continue to exchange it for new access tokens even after the victim completes the 'Forgot password' recovery flow. Because `passwordForgot` fails to delete the user's refresh tokens, the stolen credential survives the password reset and grants persistent unauthorized access.
Affected code
The `passwordForgot` flow in NocoDB only rotated `token_version` and revoked OAuth tokens but did **not** call `UserRefreshToken.deleteAllUserToken(user.id)`, leaving any previously stolen refresh token valid. The patch in `patch_id=6352789` is a migration-order fix and does **not** address this vulnerability; the advisory itself identifies the missing deletion call as the root cause.
What the fix does
The advisory states that `passwordChange` and `passwordReset` correctly call `UserRefreshToken.deleteAllUserToken(user.id)`, but `passwordForgot` omitted this call. The fix must add that same deletion call to the `passwordForgot` handler so that all refresh tokens are revoked when a user initiates a password recovery. The patch bundled here (`patch_id=6352789`) only reorders migration steps and does **not** implement this fix; the advisory's remediation guidance is the authoritative source.
Preconditions
- inputThe attacker must have previously obtained the victim's refresh token (e.g., via XSS, network interception, or a compromised device).
- inputThe victim must trigger the 'Forgot password' recovery flow (password reset via email link).
Generated on Jun 17, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.