Public March 2026
NocoDB Missed Ownership Checks in MCP Token Operations
BugBunny.ai found that NocoDB’s MCP token service let a user read, regenerate, or delete another user’s token when the token identifier was known. The issue was limited by role requirements and token-ID knowledge, but it still broke the intended ownership boundary inside a shared base.
TL;DR
Authorized users can interfere with or reveal another user’s MCP token if they know its identifier.
Token-management operations that accept a token ID but do not filter by the current user.
NocoDB releases up to and including 0.301.2.
Published and fixed in NocoDB 0.301.3.
Root Cause
McpTokenService.get(), regenerateToken(), and delete() operated solely on the token identifier and never constrained the query by fk_user_id. The analogous API token service already enforced ownership correctly.
That inconsistency meant the project had the right security model but failed to apply it uniformly. Once a user had the necessary role and discovered a valid token ID, token secrecy and integrity depended on an authorization check that never happened.
Product
NocoDB
Affected
<= 0.301.2
Patched
0.301.3
Weaknesses
CWE-639: Authorization Bypass Through User-Controlled Key
Mitigation
- Upgrade to NocoDB 0.301.3 or later.
- Require ownership checks on every token operation, not only at creation time.
- Treat token identifiers as sensitive references and avoid exposing them in logs or unrelated API responses.
Credits & Disclosure
Published via GitHub Security Advisory GHSA-p9x3-w98f-7j3q after coordinated disclosure with the NocoDB maintainers.