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.

References

• GHSA-m5qg-rvjq-727p