Public March 2026
NocoDB Failed to Revoke Refresh Tokens During Password Reset
BugBunny.ai discovered that NocoDB’s password reset flow invalidated existing JWT versions but forgot to revoke stored refresh tokens. Any attacker holding a previously stolen refresh token could continue minting fresh access tokens after the victim changed their password.
TL;DR
Compromised refresh tokens remain valid after password reset, extending account takeover windows.
Previously stolen refresh tokens reused after a victim completes password reset.
NocoDB releases up to and including 0.301.2.
Published and fixed in NocoDB 0.301.3.
Root Cause
The passwordReset() path updated token_version but did not call the refresh-token deletion routine that NocoDB already used in safer flows like passwordChange() and signOut().
Because refreshToken() only checked token existence and not token_version, a stolen refresh token stayed valid until natural expiration. The reset changed the password without actually terminating the long-lived session artifact that mattered most.
Product
NocoDB
Affected
<= 0.301.2
Patched
0.301.3
Weaknesses
CWE-613: Insufficient Session Expiration
Mitigation
- Upgrade to NocoDB 0.301.3 or later.
- Delete all user refresh tokens during password reset and password change flows.
- Audit session invalidation logic so every credential reset path revokes long-lived tokens consistently.
Credits & Disclosure
Published via GitHub Security Advisory GHSA-x4vh-j75g-268g after coordinated disclosure with the NocoDB maintainers.