PT-2026-42634 · Npm · Nocodb

Published

2026-05-21

·

Updated

2026-05-21

CVSS v3.1

2.0

Low

VectorAV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N

Summary

The OAuth token strategy attached oauth scope and oauth granted resources to the request user, but the ACL middleware never consulted either. An OAuth token issued with a restricted scope (e.g. MCP-only) therefore inherited the full permissions of the underlying user across all routes; the granted resources.base id restriction was bypassed on org-level endpoints that don't populate req.context.base id.

Details

In packages/nocodb/src/strategies/oauth-token.strategy.ts, the strategy set is oauth token, oauth client id, oauth granted resources, and oauth scope on the user object, then mapped through to the user's existing roles / base roles. The ACL middleware in extract-ids.middleware.ts honoured is api token via blockApiTokenAccess but had no equivalent gate for is oauth token or scope-string enforcement.
The base/workspace restriction logic short-circuited when req.context.base id was unset (org-level routes), so an OAuth token scoped to one base could still call org-level endpoints as the underlying user.
The fix adds a path-prefix allowlist (['/mcp', '/api/v3/', '/auth/user/me']) enforced inside the strategy and a blockOAuthTokenAccess ACL flag for endpoints that should never accept OAuth tokens.

Impact

  • Scope escalation: tokens issued with a narrow scope received the underlying user's full role.
  • Resource boundary bypass: per-base restrictions did not apply to org-level routes.
  • Violates least-privilege expectation for third-party OAuth integrations.

Credit

This issue was reported by @ik0z.

Fix

Incorrect Authorization

Weakness Enumeration

CWE-863

Related Identifiers

GHSA-M5QG-RVJQ-727P

Affected Products

Nocodb