PT-2026-42675 · Npm · Nocodb
Published
2026-05-21
·
Updated
2026-05-21
·
CVE-2026-46549
CVSS v3.1
2.0
Low
| Vector | AV: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
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Nocodb