NOCODB · CVE-2026-28361 · Package
FIX → 0.301.3
NocoDB's MCP token service does not check who owns a token before reading, regenerating or deleting it. A user with the Creator role in the same base can act on another user's MCP token if they know its ID, which can disable tokens or expose a scoped token.
first public Mar 2, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Teams that self-host NocoDB with MCP tokens enabled and give users the Creator role in a shared base. The flaw needs an account with Creator access and the target token's ID, so instances where everyone is an admin or MCP is unused carry less practical risk. Teams on hosted NocoDB Cloud are handled by the vendor.
Not affected if managed-hosting, mcp-unused
Who cares cwe-639, mcp, nocodb, self-hosted
nocodb (for example npm ls nocodb) and compare it to 0.301.3.0.301.3.Upgrade to 0.301.3
nocodb (npm): move to or later.The MCP token service did not validate token ownership, allowing a Creator within the same base to read, regenerate, or delete another user's MCP tokens if the token ID was known.
McpTokenService.get(), regenerateToken(), and delete() did not filter by fk_user_id. The analogous ApiTokensService correctly enforced ownership.
Limited — requires Creator role and knowledge of target token ID. Primary risk is denial of service (invalidating tokens) and scoped token disclosure.
This issue was reported by @bugbunny-research (bugbunny.ai).
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
0.301.3GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.