MEDIUM 5.8

CVE-2026-46552: NocoDB Shared-Base Access Control Bypass Allows Unauthorized Member Enrollment

NocoDB, a database-as-spreadsheet application, contains a flaw in how it enforces access control for shared bases. An attacker who obtains a shared-base link identifier (xc-shared-base-id) can impersonate a legitimate viewer, enumerate the members of that database, and send invitations to arbitrary email addresses. Those invitations, when accepted, grant persistent authenticated access to the database—access that persists even if the original shared link is revoked. The vulnerability stems from the application failing to distinguish between genuine authenticated users and those accessing via a shared session, allowing the latter to perform actions restricted to real members.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.8 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Weaknesses (CWE)
CWE-285
Affected products
0 configuration(s)
Published / Modified
2026-06-23 / 2026-06-25

NVD description (verbatim)

NocoDB is software for building databases as spreadsheets. Prior to 2026.04.1, shared-base sessions were granted the same base-member capabilities as authenticated viewers. Using only the shared-base UUID (xc-shared-base-id), an attacker could enumerate base members and invite an arbitrary email into the base as a real member. The invited user could then redeem the invite via the normal signup flow and retain authenticated access even after the owner revoked the shared link. Shared-base sessions were mapped to ProjectRoles.VIEWER in packages/nocodb/src/strategies/base-view.strategy/base-view.strategy.ts, and packages/nocodb/src/utils/acl.ts granted baseUserList and userInvite to that role. The shared frontend (packages/nc-gui/composables/useApi/interceptors.ts) deliberately removed auth headers in favour of the shared-base header, but the ACL middleware did not distinguish shared sessions from genuine viewers. This vulnerability is fixed in 2026.04.1.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability exists in NocoDB's access control layer across multiple components. Shared-base sessions are incorrectly mapped to ProjectRoles.VIEWER in base-view.strategy.ts, and the ACL middleware in acl.ts inadvertently grants baseUserList and userInvite permissions to that role. The shared frontend (useApi/interceptors.ts) strips authentication headers in favor of the shared-base header, but the ACL enforcement does not differentiate between shared sessions and authenticated viewer accounts. This allows an attacker with only the shared-base UUID to invoke member enumeration and user invitation endpoints as if they were a legitimate base member. The invited user receives a valid signup invitation that, once redeemed, provides persistent authenticated session access independent of the shared link's revocation status.

Business impact

Organizations using NocoDB for sensitive data sharing risk unauthorized member enumeration, phishing attacks through fraudulent invitations sent to external addresses, and loss of access control when shared links are meant to be temporary. An attacker can permanently graft unauthorized users into a database, bypassing the owner's intention to limit exposure. This undermines the security model of temporary, revocable sharing and creates persistent unauthorized access paths that may go undetected until abuse occurs.

Affected systems

All NocoDB installations prior to version 2026.04.1 are affected. The vulnerability applies to any shared base that is accessed via the xc-shared-base-id mechanism, making any deployment sharing databases with external parties at risk.

Exploitability

Exploitation requires only network access and knowledge of a valid shared-base UUID. No authentication credentials, user interaction, or special configuration is required; an attacker can enumerate members and send invitations immediately upon obtaining the identifier. The attack is straightforward and does not depend on complex manipulation or race conditions. The CVSS score of 5.8 (Medium) reflects the network-based, low-complexity nature of the attack, constrained by the limited scope of the shared-base context and the fact that confidentiality impact (enumeration) is present but integrity and availability are not directly affected.

Remediation

Upgrade to NocoDB version 2026.04.1 or later, which corrects the ACL enforcement logic to properly distinguish shared sessions from authenticated members and restricts sensitive operations (baseUserList, userInvite) to genuinely authenticated users. After patching, audit existing base invitations and membership lists to identify and remove unauthorized or suspicious accounts introduced during the exposure window.

Patch guidance

Install NocoDB 2026.04.1 or any subsequent release. Patch immediately in shared-base deployments, as the vulnerability is easily triggered by anyone with access to a shared link identifier. Verify the patch has been applied by checking the NocoDB version in your deployment and reviewing the base-view.strategy and acl middleware implementations to confirm the ACL distinction has been restored. Plan the upgrade during a maintenance window if NocoDB is in production.

Detection guidance

Monitor audit logs for unusual member enumeration patterns or unexpected user invitations sent from shared-base sessions (identified by xc-shared-base-id header without corresponding authentication tokens). Look for invitations to external email addresses that do not correspond to known organizational users, or a spike in baseUserList API calls originating from shared-link access paths. If available, enable network telemetry to track anomalous access to shared-base endpoints that perform sensitive operations. Review base membership and compare against expected users; accounts created shortly after a shared link became active warrant investigation.

Why prioritize this

Although the CVSS score is Medium, prioritize patching because: (1) the attack requires no authentication or user interaction, (2) the vulnerability enables persistent access gain (not just temporary information disclosure), (3) shared links are often used in sensitive or confidential workflows where unauthorized membership is particularly damaging, and (4) revocation of the shared link does not remove the attacker's persistent access, making the threat window effectively unlimited until bases are audited and compromised accounts are removed.

Risk score, explained

CVSS 5.8 (Medium) reflects a network-accessible vulnerability with low complexity and no privilege requirement. Confidentiality impact is low (member enumeration and invitation history may be observed), integrity and availability are not impacted in the CVSS model, and scope is changed because the attack affects the security posture of users outside the shared-base resource itself. However, the practical risk is elevated relative to the score because the vulnerability enables account injection with persistent consequences, and shared bases are often used for sensitive external collaboration.

Frequently asked questions

Can an attacker read the actual data in the database without being a real member?

No. This vulnerability allows enumeration of base members and sending of invitations. Reading the actual database contents would require either accepting and redeeming the invitation (which then grants persistent access) or exploiting a separate vulnerability. The attacker's initial foothold via the shared-base UUID is limited to membership operations.

If we revoke the shared link, does that remove accounts the attacker invited?

No. Revoking the shared link does not delete or disable user accounts that were already invited and activated. An attacker who invited a malicious email and that user completed signup has persistent authenticated access. You must manually review and remove unauthorized accounts from the base membership.

Do we need to re-share the base after patching?

Not necessarily. After upgrading to 2026.04.1, the access control logic is corrected and new shared-base sessions will no longer have member enumeration or invitation privileges. However, audit existing base membership to ensure no unauthorized accounts were added while unpatched. Existing shared links can continue to be used once you are confident the base membership is clean.

How do I tell if our NocoDB was exploited during this window?

Review base membership and invitation history, particularly accounts created or invited while a shared link was active. Check audit logs for baseUserList or userInvite API calls originating from shared-base sessions (look for xc-shared-base-id headers without corresponding authentication). Examine newly added members to determine whether they correspond to legitimate invitations. If you find suspicious accounts, remove them and consider changing shared-link UUIDs if the link was compromised.

This analysis is based on the vulnerability information available as of the publication date. Security researchers and organizations should verify vendor advisories and release notes before patching. CVSS scores and severity ratings are provided for context; actual organizational risk depends on deployment configuration, exposure of shared-base UUIDs, and sensitivity of data in affected bases. This explainer does not constitute security advice specific to any particular system; consult with your security team and the vendor for guidance tailored to your environment. Source: NVD (public-domain), retrieved 2026-07-29. Analysis generated by SEC.co (claude-haiku-4-5).