CVE-2026-53928Medium▾ SunlitNocoDB: Refresh Tokens Persist Through Password Recovery
▾ Sunlit zone — Low / medium · no exploitation signal
impact 27.5 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 4.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.2%
0.2% → 0.3%
A stolen refresh token survived a password-forgot flow and could be used to mint fresh JWTs even after the user reset their password.
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.
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.
This issue was reported by @bugbunny-research.
nocodb <= 0.301.3Refer to the advisory for the patched release.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-53927MediumNocoDB: Server-Side Request Forgery via Spreadsheet Fetch URL
CVE-2026-53929MediumNocoDB: Stored Cross-Site Scripting via Secure Attachment
CVE-2026-53930MediumNocoDB: Server-Side Request Forgery via Base Migration URL
CVE-2026-53931MediumNocoDB: Server-Side Request Forgery via Spreadsheet Import Endpoint
CVE-2026-53517High· 8.1Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption
GHSA-2vg6-77g8-24mpLow· 3.8Better Auth: Stale sessions persist after user deletion across admin, anonymous, and SCIM flows