GHSA-M5QG-RVJQ-727P
Vulnerability from github – Published: 2026-05-21 20:34 – Updated: 2026-07-20 21:16Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nocodb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.301.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46549"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T20:34:51Z",
"nvd_published_at": "2026-06-23T21:16:58Z",
"severity": "LOW"
},
"details": "### Summary\n\nThe 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\u0027t populate `req.context.base_id`.\n\n### Details\n\nIn `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\u0027s 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.\n\nThe 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.\n\nThe fix adds a path-prefix allowlist (`[\u0027/mcp\u0027, \u0027/api/v3/\u0027, \u0027/auth/user/me\u0027]`) enforced inside the strategy and a `blockOAuthTokenAccess` ACL flag for endpoints that should never accept OAuth tokens.\n\n### Impact\n\n- Scope escalation: tokens issued with a narrow scope received the underlying user\u0027s full role.\n- Resource boundary bypass: per-base restrictions did not apply to org-level routes.\n- Violates least-privilege expectation for third-party OAuth integrations.\n\n### Credit\n\nThis issue was reported by [@ik0z](https://github.com/ik0z).",
"id": "GHSA-m5qg-rvjq-727p",
"modified": "2026-07-20T21:16:10Z",
"published": "2026-05-21T20:34:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-m5qg-rvjq-727p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46549"
},
{
"type": "PACKAGE",
"url": "https://github.com/nocodb/nocodb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "NocoDB: OAuth Token Scope Not Enforced at ACL Layer Allows Scope Escalation"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.