CVE-2026-28361: IDOR in NocoDB MCP Token Service

CVE-2026-28361 is an Insecure Direct Object Reference (IDOR) vulnerability affecting the Model Context Protocol (MCP) integration in NocoDB. The vulnerability manifests in the backend service layer responsible for managing MCP tokens, specifically within the McpTokenService. This component is designed to handle the lifecycle of authentication tokens used for Model Context Protocol interactions.

In affected versions, the application enforces role-based access control (RBAC) to ensure only users with 'Creator' privileges can access these endpoints. However, it fails to implement horizontal privilege separation. This means that while the application correctly verifies that a user is a 'Creator', it does not verify that the specific token being accessed belongs to that user. Consequently, the API treats all tokens within a base as globally accessible to any authorized creator within that scope, violating the principle of least privilege.

This flaw allows a malicious actor to perform unauthorized actions on sensitive resources. While the requirement to know the target Token ID mitigates the risk slightly (assuming IDs are non-sequential UUIDs), leaks in logs, error messages, or client-side code could expose these identifiers, making exploitation trivial.

The root cause of this vulnerability is a missing ownership validation check in the database query logic of the McpTokenService. When an API request is received to get, regenerate, or delete a token, the backend extracts the tokenId from the request parameters and uses it to look up the record in the database.

Technically, the vulnerability exists because the database operations (such as findOne or delete) rely solely on the primary key (id) of the token record. A secure implementation of the repository pattern for user-owned resources must typically include a composite filter: the resource id AND the owner_id (or fk_user_id). By omitting the fk_user_id constraint, the service returns the record regardless of who owns it, provided the record exists.

This oversight stands in contrast to other services within the NocoDB codebase, such as the ApiTokensService, which correctly implements these scope checks. The discrepancy suggests that the MCP Token service was likely a newer addition where standard security patterns were not consistently applied during initial development.

The remediation involves enforcing strict ownership boundaries at the service layer. Below is a conceptual representation of the vulnerable code versus the secure implementation introduced in version 0.301.3.

Vulnerable Implementation

In the vulnerable version, the get method queries the database using only the token ID provided in the arguments. The user object, while potentially available in the context, is ignored during the database lookup.

// McpTokenService.ts (Vulnerable)
 
async get(id: string) {
  // FLAW: Query relies solely on the public ID.
  // If 'id' exists, it is returned regardless of the requester.
  return await this.db.mcp_tokens.findOne({
    where: { id }
  });
}
 
async delete(id: string) {
  // FLAW: Deletion occurs without verifying ownership.
  return await this.db.mcp_tokens.delete({
    where: { id }
  });
}

Patched Implementation

The patch modifies the function signatures to accept the authenticated user object and incorporates the user's ID into the where clause of the database query. This ensures that the database only returns a result if both the Token ID matches AND the fk_user_id matches the requester.

// McpTokenService.ts (Fixed)
 
async get(id: string, user: User) {
  // FIX: Added 'fk_user_id' to the query criteria.
  // This acts as a mandatory horizontal authorization check.
  return await this.db.mcp_tokens.findOne({
    where: {
      id,
      fk_user_id: user.id 
    }
  });
}
 
async delete(id: string, user: User) {
  return await this.db.mcp_tokens.delete({
    where: {
      id,
      fk_user_id: user.id
    }
  });
}

Exploiting this vulnerability requires an attacker to have a valid account with 'Creator' privileges on a NocoDB instance. The primary hurdle for the attacker is obtaining the target tokenId. If these IDs are sequential integers, enumeration is trivial. If they are UUIDs, the attacker must rely on secondary information leaks (e.g., shared browser sessions, leaked logs, or predictable generation seeds).

Attack Scenario:

1. Reconnaissance: The attacker identifies the API endpoint structure, typically /api/v1/db/meta/mcp-tokens/{tokenId}.
2. Target Acquisition: The attacker obtains a valid tokenId belonging to another user (User B).
3. Execution: The attacker (User A) sends a DELETE request to the endpoint using User B's tokenId.

DELETE /api/v1/db/meta/mcp-tokens/550e8400-e29b-41d4-a716-446655440000 HTTP/1.1
Host: nocodb-instance.local
Authorization: Bearer <User_A_Token>
Content-Type: application/json

Result: In a vulnerable instance, the server processes the deletion and returns 200 OK. User B's workflow relying on that token immediately breaks. If the attacker sent a GET request instead, they would receive the sensitive token details in the response body.

The impact of CVE-2026-28361 is classified as Medium (CVSS 4.9) primarily because it requires authentication and specific knowledge of resource IDs. However, for organizations using NocoDB in collaborative environments, the consequences of successful exploitation are significant.

Integrity Impact (High): The ability to regenerate or delete tokens allows an attacker to disrupt the workflows of other users. Regenerating a token invalidates the previous one, causing immediate denial of service for any external scripts or integrations relying on that credential.

Confidentiality Impact (Low/Medium): While the CVSS v4 vector in the research context rates Confidentiality as None (VC:N), this is specific to the analyzed context. If the API response body includes the actual secret token string upon a successful GET request, the confidentiality impact would technically be High for that specific scope. Access to these tokens could allow the attacker to impersonate the victim in interactions with the Model Context Protocol, potentially leading to further data exposure.