Listen to this Post
The OAuth token strategy in NocoDB attaches `oauth_scope` and `oauth_granted_resources` to the request user, but the ACL middleware never consults these fields. A token issued with a restricted scope—for example, limited to MCP operations—unexpectedly inherits the full permissions of the underlying user. This occurs because the strategy sets is_oauth_token, oauth_client_id, oauth_granted_resources, and `oauth_scope` on the user object, yet the ACL middleware in `extract-ids.middleware.ts` lacks an equivalent gate for `is_oauth_token` or scope‑string enforcement. Consequently, the base/workspace restriction logic short‑circuits when `req.context.base_id` is unset (such as on org‑level endpoints), allowing an OAuth token scoped to one base to freely call org‑level endpoints as the underlying user. The fix introduces a path‑prefix allowlist (['/mcp', '/api/v3/', '/auth/user/me']) enforced inside the strategy and adds a `blockOAuthTokenAccess` ACL flag for endpoints that must never accept OAuth tokens.
dailycve form
Platform: NocoDB
Version: 0.301.3
Vulnerability: OAuth ACL Bypass
Severity: Low
Date: 2026-05-21
Prediction: 2026-05-22
What Undercode Say
Analytics:
- Attack surface increases because OAuth tokens are not validated at the ACL layer, affecting all org‑level routes.
- The bypass is detected by monitoring for `is_oauth_token` set without corresponding scope evaluation.
- The path‑prefix allowlist (
/mcp,/api/v3/,/auth/user/me) reduces risk but does not eliminate the need for proper ACL integration.Check your NocoDB version docker exec nocodb-app node -e "console.log(require('./package.json').version)" List OAuth-related environment variables env | grep -i OAUTH Review ACL middleware for is_oauth_token checks (from source) grep -A10 "is_oauth_token" packages/nocodb/src/strategies/oauth-token.strategy.ts grep -A10 "blockApiTokenAccess" packages/nocodb/src/middlewares/extract-ids.middleware.tsTest if OAuth token is honored without scope evaluation import requests token = "YOUR_OAUTH_TOKEN" headers = {"Authorization": f"Bearer {token}"} Attempt to access an org-level endpoint with a base-scoped token response = requests.get("https://your-nocodb-instance.com/api/v1/org/some-endpoint", headers=headers) if response.status_code == 200: print("Vulnerable: OAuth token used without scope evaluation") else: print("Probably fixed")
Exploit
An attacker obtains an OAuth token restricted to a single base (e.g., via a third‑party integration). Using that token, they call an org‑level endpoint (like /api/v1/org/) that does not populate req.context.base_id. The ACL middleware skips base/workspace restrictions and grants the attacker the full permissions of the underlying user, bypassing the intended least‑privilege boundary.
Protection from this CVE
- Upgrade to a NocoDB version that includes the path‑prefix allowlist and the `blockOAuthTokenAccess` ACL flag (0.301.4 or later).
- If patching is not immediately possible, restrict network access to org‑level endpoints for any OAuth‑authenticated requests using a reverse proxy (e.g., nginx).
- Enforce manual scope validation at the application level for any endpoint that should not accept OAuth tokens, using the `blockOAuthTokenAccess` flag.
- Regularly audit OAuth client configurations and ensure tokens are issued with the minimum necessary scope.
Impact
- Scope escalation: A token issued with a narrow scope (e.g., MCP‑only) grants the full role of the underlying user, breaking the least‑privilege principle.
- Resource boundary bypass: Tokens limited to a single base can still access org‑level endpoints, circumventing per‑base restrictions.
- Third‑party integration risk: External OAuth integrations may unintentionally gain full control over the NocoDB instance, leading to data leakage or manipulation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
