CVE-2026-53928
MediumCVSS 6.3Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
NocoDB prior to version 2026.05.1 had a vulnerability where a stolen refresh token could be used to mint new JWTs even after the user reset their password. The password forgot flow did not delete all refresh tokens, allowing an attacker to exchange the captured token for a new access token.
Risk Assessment
The organization may be exposed to unauthorized access to user data if an attacker possesses a stolen refresh token. This could lead to serious security breaches and data loss.
Recommendation
It is recommended to update NocoDB to version 2026.05.1 or later to eliminate this vulnerability. Additionally, conducting a security audit to identify and revoke any stolen tokens is advisable.
Other vulnerabilities in NocoDB
See all- CVE-2023-35843High
NocoDB through 0.106.0 (or 0.109.1) has a path traversal vulnerability that allows an unauthenticated attacker to access arbitrary files on the server by manipulating the path parameter of the /download route.
- CVE-2026-53931Medium
NocoDB prior to version 2026.05.1 had a vulnerability that allowed the spreadsheet-import endpoint axiosRequestMake to be used as a generic HTTP proxy. This endpoint was accessible unauthenticated, enabling unauthorized access.
- CVE-2026-53930Medium
NocoDB prior to version 2026.05.1 had a vulnerability in the base-migration endpoint that accepted a caller-supplied URL without enforcing protocol or destination. This allowed scheme abuse and probing of internal HTTP destinations.
- CVE-2026-53929Medium
NocoDB prior to version 2026.05.1 allowed authenticated uploaders to deliver .html or .svg attachments that were rendered inline in the browser instead of forcing a download. The issue stemmed from a mismatch in how response headers were handled, leading to automatic rendering of these files.
- CVE-2026-53927Medium
NocoDB prior to version 2026.05.1 had a vulnerability in the spreadsheet-fetch endpoint (axiosRequestMake) that accepted URLs with a permitted extension anywhere in the string. This allowed access to the cloud-metadata endpoint via a crafted URL.
- CVE-2026-53926Medium
NocoDB prior to version 2026.05.1 had a vulnerability in the users service where the revokeAllOAuthTokensByUser function was an empty stub. As a result, OAuth tokens were not revoked when the user changed, reset, or recovered their password.
- CVE-2026-47388Low
NocoDB prior to version 2026.05.1 allowed low-privilege users to read files in shared storage, including attachments belonging to other bases and workspaces, if they knew the attachment path. This issue was due to the MCP readAttachment tool not verifying file ownership.
- CVE-2026-47386Medium
NocoDB prior to version 2026.05.1 had a vulnerability that allowed two concurrent uses of the same OAuth authorization code to generate two distinct valid (access_token, refresh_token) pairs. This broke the single-use guarantee that PKCE relies on.
- CVE-2026-47385Medium
NocoDB prior to version 2026.05.1 allowed authenticated users with base-create permissions to attach a SQLite source pointing at any file on the NocoDB host, including NocoDB's internal databases. Users could point to noco.db or other databases, enabling them to read or overwrite their contents.
- CVE-2026-47384Medium
NocoDB prior to version 2026.05.1 allows authenticated users with column-create permission to inject SQL into the bulk groupBy endpoint. This can be achieved by setting a column's title to a SQL fragment, bypassing the existing column allowlist.
Original NVD description (English source)
NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, 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. This vulnerability is fixed in 2026.05.1.

