What is the CVSS score of CVE-2026-46549?

CVE-2026-46549 has a CVSS 3.1 base score of 2.0 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-46549?

Yes, a patch is available for CVE-2026-46549. Update the affected software to the latest version immediately.

NocoDB CVE-2026-46549

EUVD-2026-38586 LOW

Incorrect Authorization (CWE-863)

2026-05-21 https://github.com/nocodb/nocodb

GHSA-m5qg-rvjq-727p

Authentication Bypass

2.0

CVSS 3.1 · Vendor: https://github.com/nocodb/nocodb

Severity by source

Vendor (https://github.com/nocodb/nocodb) PRIMARY

2.0 LOW

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

Primary rating from Vendor (https://github.com/nocodb/nocodb) · only source for this CVE.

CVSS VectorVendor: https://github.com/nocodb/nocodb

CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

Required

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 23, 2026 - 23:02 EUVD

Source Code Evidence Fetched

May 21, 2026 - 21:35 vuln.today

Analysis Generated

May 21, 2026 - 21:35 vuln.today

DescriptionCVE.org

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.

AnalysisAI

OAuth token scope enforcement is entirely absent at the ACL middleware layer in NocoDB (npm/nocodb ≤ 0.301.3), causing tokens issued with restricted scopes - such as MCP-only - to silently inherit the underlying authenticated user's full role across all routes. The per-base resource restriction (granted_resources.base_id) is additionally bypassed on org-level endpoints where req.context.base_id is never populated, rendering base-scoped token restrictions meaningless against workspace-level API calls. No public exploit has been identified at time of analysis, and no patched release has been confirmed despite a fix being described in the advisory.

Technical ContextAI

NocoDB is an open-source no-code database platform distributed as an npm package (pkg:npm/nocodb). The root cause is CWE-863 (Incorrect Authorization): authentication succeeds correctly, but post-authentication authorization fails to consult OAuth-specific attributes. In packages/nocodb/src/strategies/oauth-token.strategy.ts, the strategy correctly attaches is_oauth_token, oauth_client_id, oauth_granted_resources, and oauth_scope to the request user object, but then maps through the user's existing roles and base_roles without restriction. The ACL middleware in extract-ids.middleware.ts implements a blockApiTokenAccess gate keyed on is_api_token, but contains no equivalent blockOAuthTokenAccess gate or scope-string enforcement. The granted_resources.base_id boundary check short-circuits when req.context.base_id is absent, which is the normal state for org-level routes, creating a systematic bypass for any OAuth token regardless of its declared scope.

RemediationAI

No vendor-released patch has been identified at time of analysis - the GitHub advisory (https://github.com/nocodb/nocodb/security/advisories/GHSA-m5qg-rvjq-727p) lists no fixed version. The advisory does describe the intended fix: addition of a path-prefix allowlist (['/mcp', '/api/v3/', '/auth/user/me']) enforced inside the OAuth token strategy, and a blockOAuthTokenAccess ACL flag for endpoints that should never accept OAuth tokens. Operators capable of self-patching from the upstream fix description may apply this change, but no released version independently confirms its inclusion. As a compensating control, organizations should disable OAuth token issuance entirely if MCP or scoped OAuth flows are not actively required - this eliminates the attack surface with no functional trade-off for non-OAuth deployments. If OAuth must remain enabled, restrict org-level API endpoints at the network or API gateway layer to trusted internal clients only. Audit all issued OAuth tokens to review their declared scopes versus the resources they can actually reach. Monitor https://github.com/nocodb/nocodb/security/advisories/GHSA-m5qg-rvjq-727p for patch release.