CVE-2026-46552

NocoDB Shared-Base-Links können echte Base-Mitglieder einladen und den Widerruf der Freigabe überleben

Einleitung

Ich habe dieses Problem gefunden, während ich NocoDB überprüft habe, mit einer einfachen Sicherheitsfrage im Kopf:

Kann ein öffentlicher Shared-Base-Link die Grenze von temporärem gemeinsamem Zugang zur echten authentifizierten Base-Mitgliedschaft überschreiten?

In diesem Fall war die Antwort ja.

Eine Shared-Base-Sitzung, die nur durch xc-shared-base-id authentifiziert war, wurde für ACL-Zwecke als normaler Base-Viewer behandelt. Da Viewer-Berechtigungen immer noch Member-Management-Endpunkte erreichten, konnte ein Benutzer mit nur der Shared-Base-UUID vorhandene Base-Mitglieder aufzählen und eine beliebige E-Mail-Adresse als echtes Mitglied in die Base einladen.

Dieser eingeladene Benutzer konnte dann die Einladung über den normalen Anmeldevorgang einlösen, ein standardmäßig authentifiziertes Konto erhalten und den Base-Zugang behalten, selbst nachdem der Besitzer den Shared-Base-Link deaktiviert hatte.

Dieses Problem wurde zu CVE-2026-46552.

Projekt: NocoDB

Bestätigte betroffene Version: 0.301.3

Dies betraf NocoDB, auf seiner offiziellen Website wird NocoDB als vertrauenswürdig von 35.000+ Organisationen und mit 20+ Millionen Downloads präsentiert. Die Website listet auch Unternehmen wie Accenture, Western Digital, Hyundai, Walmart, PwC, Bosch und American Express.

Angriffskette

public shared-base link -> xc-shared-base-id treated as normal base viewer -> viewer ACL reaches member-management endpoints -> attacker lists base users and invites arbitrary email -> invited user redeems normal signup token -> durable authenticated base access survives shared-link revocation

Was NocoDB macht

NocoDB ist eine datenbankorientierte Kollaborationsplattform, die browserbasierten Base-Zugriff, Freigabe, Metadatenverwaltung und Benutzermitgliedschafts-Workflows bereitstellt.

Das bedeutet, dass sein Freigabemodell eine echte Sicherheitsgrenze ist.

Die wichtige Frage hier war nicht, ob Shared-Base-Links gemeinsam genutzte Inhalte lesen können.

Die eigentliche Frage war:

Kann ein öffentlicher Freigabe-Prinzipal Aktionen ausführen, die nur authentifizierten Base-Mitgliedern gehören sollten?

In diesem Fall konnte er.

Warum diese Oberfläche einen Blick wert war

Öffentliche Freigabefunktionen werden leicht unterschätzt.

Das ist ein Fehler.

Sobald eine Anwendung Folgendes unterstützt:

• anonymen oder linkbasierten Zugriff,
• Rollenzuordnung,
• und gewöhnliche authentifizierte Management-APIs hinter demselben ACL-System,

ist das Hauptrisiko nicht nur die Datenpreisgabe.

Das stärkere Risiko ist der Grenzzusammenbruch:

• ein weniger vertrauenswürdiger Prinzipal erbt Fähigkeiten mit höherem Vertrauen,
• Management-Aktionen werden aus einem öffentlichen Freigabekontext erreichbar,
• und temporärer Zugriff kann in dauerhaften Zugriff umgewandelt werden.

Das war das eigentliche Problem hier.

Dies war kein Fehler in der Anmeldevalidierung. Es war kein Token-Fälschungsproblem. Es war kein Passwort-Reset-Fehler.

Es war ein klassischer Autorisierungsgrenzfehler:

• ein Shared-Link-Prinzipal wurde in normale Base-Rollen abgebildet,
• diese Rollen enthielten immer noch Member-Management-Fähigkeiten,
• und der echte dauerhafte Zugriffskontrollzustand konnte dann aus dem öffentlichen Freigabekontext geändert werden.

Die Grenze, auf die ich mich konzentriert habe

Ich bin nicht so vorgegangen, dass ich zufällig Endpunkte abgefragt und gehofft habe, dass etwas Interessantes antwortet.

Der stärkere Weg war, zuerst die wertvollste Vertrauensgrenze zu identifizieren.

Für NocoDB war das die Grenze zwischen:

• Shared-Base-Zugriff
• und authentifizierter Base-Mitgliedschaft

Diese beiden Zustände sollten nicht austauschbar sein.

Ein Shared-Base-Link soll einen abgegrenzten, widerrufbaren, linkbasierten Zugriff darstellen. Er sollte keine neuen langlebigen Prinzipale innerhalb der Base erzeugen können.

Das ist genau die Grenze, die hier versagt hat.

Ursache

Die Schwachstelle entstand dadurch, wie Shared-Base-Zugriff in den normalen ACL-Pfad integriert wurde.

Im Shared-Base-Frontend-Flow wurde xc-shared-base-id injiziert, während normale Auth-Header entfernt wurden.

Dann akzeptierte BaseViewStrategy im Backend xc-shared-base-id und übersetzte den geteilten Link direkt in normale roles / base_roles, die aus der Shared-Base-Konfiguration abgeleitet wurden.

Das war das erste Problem.

Das zweite Problem war, dass Viewer-Level-Berechtigungen immer noch Member-Management-Aktionen beinhalteten.

In der ACL-Ebene konnte ProjectRoles.VIEWER Folgendes erreichen:

• baseUserList
• userInvite

Diese Berechtigungen schützten normale Meta-Routen:

• GET /api/v2/meta/bases/:baseId/users
• POST /api/v2/meta/bases/:baseId/users

Eine öffentliche Freigabesitzung durfte also effektiv Mitgliedschafts-Endpunkte ansprechen, die für echte Base-Teilnehmer vorgesehen waren.

Der letzte Schritt war im Einladungsfluss selbst.

BaseUsersService.userInvite() überprüfte die Rollenmacht und erstellte dann:

• eine echte Benutzerzeile mit einem invite_token
• eine echte Base-Mitgliedschaftszeile für die Ziel-Base

Und für Shared-Base-Sitzungen:

• wurde invited_by zu null

weil es keine echte authentifizierte Einladenden-Identität hinter der Anfrage gab.

Das ist die gesamte Fehlerkette.

Warum dies ausnutzbar ist

Weil der Besitz eines Shared-Base-Links ausreichte.

Der Angreifer brauchte nicht:

• xc-auth
• ein bereits bestehendes Konto
• gestohlene Anmeldedaten
• oder vorherige Mitgliedschaft in der Base

Die Ausnutzungskette war geradlinig:

• Der Angreifer erhält eine Shared-Base-UUID
• Die UUID wird als Base-Viewer-Prinzipal akzeptiert
• Viewer-ACL erreicht Member-Management-Endpunkte
• Der Angreifer listet aktuelle Base-Mitglieder auf
• Der Angreifer lädt eine beliebige E-Mail-Adresse ein
• Der eingeladene Benutzer löst das Token über den normalen Anmeldevorgang ein
• Das neue Konto wird zu einem echten authentifizierten Base-Mitglied
• Der Besitzer deaktiviert später den geteilten Link
• Das eingeladene Konto behält weiterhin normalen authentifizierten Zugriff

Das verwandelt widerrufbares Link-Sharing in dauerhafte Mitgliedschaft.

Was dies zu einem Sicherheitsproblem macht, nicht nur zu seltsamem Freigabeverhalten

Der wichtige Unterschied ist die Persistenz über den Widerruf hinweg.

Es ging nicht nur darum:

„Ein Viewer könnte einen Viewer-Endpunkt aufrufen“

Der anfällige Prinzipal war kein normaler authentifizierter Viewer.

Es war eine öffentliche Freigabesitzung.

Das ist wichtig, weil die Anwendung einen flüchtigen, linkgebundenen Prinzipal so behandelte, als wäre er vertrauenswürdig genug, um:

• echte Mitglieder aufzulisten,
• den Zugriffskontrollzustand zu ändern,
• und neue dauerhafte Prinzipale innerhalb der Base zu erzeugen

Die eigentliche Frage war nicht:

„Kann ein geteilter Benutzer geteilte Daten lesen?“

Die eigentliche Frage war:

„Kann öffentlicher Freigabezugriff in dauerhaften authentifizierten Zugriff umgewandelt werden, der den Widerruf der Freigabe überlebt?“

Die Antwort war ja.

Deshalb ist dies eine echte Autorisierungsschwachstelle und nicht nur überraschendes Anwendungsverhalten.

PoC

Ich habe dies lokal validiert gegen:

• Produktversion: 0.301.3
• Commit: dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad
• Basis-URL: http://127.0.0.1:8080

Die Reproduktion war geradlinig.

Zuerst meldete ich mich als normaler Besitzer an, erstellte eine neue Base, erstellte eine Tabelle und aktivierte den Shared-Base-Zugriff als viewer:

PATCH /api/v2/meta/bases/<baseId>/shared
Content-Type: application/json

{
  "roles": "viewer"
}

Das gab die Shared-Base-UUID zurück.

Dann, ohne xc-auth zu senden, verwendete ich nur:

xc-shared-base-id: <sharedBaseUuid>

Mit nur diesem Header rief ich auf:

GET /api/v2/meta/bases/<baseId>/users

Das gab 200 OK zurück und legte echte Base-Mitglieder offen, einschließlich E-Mail-Adressen.

Mit immer noch nur xc-shared-base-id rief ich auf:

POST /api/v2/meta/bases/<baseId>/users
Content-Type: application/json

{
  "email": "[email protected]",
  "roles": "viewer"
}

Das gab ebenfalls 200 OK zurück.

Für die lokale Laborvalidierung ohne E-Mail-Zustellung bestätigte ich direkt in der SQLite-Meta-Datenbank, dass:

• nc_users_v2 den eingeladenen Benutzer mit einem nicht-null invite_token enthielt
• nc_base_users_v2 eine echte Mitgliedschaftszeile für die Ziel-Base enthielt
• invited_by war NULL

Dann löste ich die Einladung über den normalen Anmeldevorgang ein:

POST /api/v2/auth/user/signup
Content-Type: application/json

{
  "email": "[email protected]",
  "password": "Password123.",
  "token": "<invite_token>"
}

Mit dem zurückgegebenen xc-auth rief ich auf:

GET /api/v2/meta/bases/<baseId>/tables

Das gab 200 OK zurück.

Schließlich deaktivierte ich als Besitzer den Shared-Base-Link:

DELETE /api/v2/meta/bases/<baseId>/shared

Danach:

• Shared-Link-Zugriff mit xc-shared-base-id schlug fehl mit 401
• Das eingeladene Konto mit normalem xc-auth hatte immer noch Erfolg mit 200

Beobachtete Ergebnisse

• geteilte Benutzerliste: 200
• geteilte Einladung: 200
• Anmeldung: 200
• eingeladener authentifizierter Tabellenzugriff vor Deaktivierung der Freigabe: 200
• Deaktivierung der Freigabe: 200
• Shared-Link-Tabellenzugriff nach Deaktivierung: 401
• eingeladener authentifizierter Tabellenzugriff nach Deaktivierung: 200

Das stellte den zentralen Sicherheitsanspruch fest:

• öffentlicher Freigabezugriff konnte Mitgliedschafts-Endpunkte erreichen
• Mitgliedschaftsänderungen erzeugten echten dauerhaften authentifizierten Zugriff
• der Widerruf der ursprünglichen Freigabe entfernte diesen Zugriff nicht

Warum die Reproduktion wichtig ist

Eine einzige erfolgreiche Shared-Base-Einladung hätte bereits ausgereicht, um einen Autorisierungsfehler zu zeigen.

Aber die vollständige Validierungskette war aus zwei Gründen wichtig.

Erstens

Es zeigte, dass dies nicht nur eine Endpunkt-Exposition war.

Die öffentliche Freigabesitzung erreichte nicht nur eine eingeschränkte API. Sie vollendete die vollständige Privilegien-Konvertierungskette:

• Mitglieder auflisten
• einen neuen Prinzipal einladen
• die Einladung einlösen
• normalen authentifizierten Zugriff erhalten

Zweitens

Es bewies, dass dies nicht selbstwiderrufend war.

Die ernstere Auswirkung trat nach der Deaktivierung des Freigabelinks ein:

• der ursprüngliche Link starb
• das vom Angreifer erstellte Konto nicht

Das ist es, was temporären Linkzugriff in dauerhafte Zugriffspersistenz verwandelte.

Auswirkungen

Diese Schwachstelle erlaubt jedem mit einem Shared-Base-Link, Folgendes zu tun:

• echte Base-Mitglieder und deren E-Mail-Adressen aufzulisten
• beliebige E-Mail-Adressen als echte Mitglieder in die Base einzuladen
• temporären linkbasierten Zugriff in dauerhafte authentifizierte Mitgliedschaft umzuwandeln
• diesen Zugriff auch dann zu behalten, wenn der Besitzer den geteilten Link widerruft

Die primäre Auswirkung ist die Vertraulichkeit, da ein Angreifer dauerhaften Lesezugriff auf Shared-Base-Daten über ein gewöhnliches authentifiziertes Konto aufrechterhalten kann.

Es gibt auch eine Integritätsauswirkung, da ein öffentlicher Freigabe-Prinzipal den Zugriffskontrollzustand ändern kann, indem er neue Mitglieder zur Base hinzufügt.

Das ist ein schwerwiegenderes Ergebnis als gewöhnlicher Datenverlust. Es ist ein Bruch der Privilegiengrenze zwischen anonymem Teilen und authentifizierter Mitgliedschaft.

Schweregrad und Klassifizierung

Dieses Problem wird vernünftigerweise als bereichsübergreifender Autorisierungsfehler mit Vertraulichkeitsauswirkung klassifiziert.

CVSS:

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

Dieser Vektor passt zum Kernverhalten hier:

• netzwerkerreichbares Verhalten
• kein vorheriges authentifiziertes Konto erforderlich
• keine Benutzerinteraktion des Opfers während der Ausnutzung erforderlich
• Bereichsänderung, da ein öffentlicher Freigabe-Prinzipal in normale Mitgliedschaftsverwaltungsfähigkeit übergeht
• Vertraulichkeitsauswirkung durch dauerhaften unbefugten Base-Zugriff

Vorgeschlagene Abhilfe

Die Richtung der Behebung ist geradlinig.

Shared-Base-Sitzungen sollten keine Member-Management-Fähigkeiten erben.

Mindestens:

• baseUserList und userInvite aus allen Berechtigungen entfernen, die über xc-shared-base-id erreichbar sind
• eine explizite Sperre erzwingen, sodass freigegebene/öffentliche Prinzipale keine Base-Mitgliedschafts-Endpunkte wie GET und POST /api/v2/meta/bases/:baseId/users aufrufen können
• Shared-Base-Zugriff als eigenständigen Prinzipaltyp behandeln, anstatt ihn direkt auf normale Base-Viewer-Berechtigungen abzubilden
• Regressionstests hinzufügen, die überprüfen, dass Shared-Base-Anfragen keine Mitglieder auflisten, keine Benutzer einladen und keinen dauerhaften Zugriff erzeugen können, der den Widerruf der Freigabe überlebt

Offenlegung

Dieses Problem wurde lokal gegen NocoDB 0.301.3 auf Commit dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad validiert.

Der Bericht demonstrierte:

• die ACL-Abbildung von xc-shared-base-id in normale Base-Rollen
• den Viewer-Berechtigungspfad in Member-Management-Endpunkte
• die Erstellung von echten eingeladenen Benutzern und Base-Mitgliedschaftszeilen
• die Fähigkeit, die Einladung über den normalen Anmeldevorgang einzulösen
• die Persistenz des authentifizierten Zugriffs nach Widerruf des Shared-Links

Das Problem wurde zugewiesen:

CVE-2026-46552

Was dieser Fehler tatsächlich lehrt

Die Kernlektion ist einfach:

Shared-Link-Zugriff ist nicht dasselbe wie vertrauenswürdige Mitgliedschaft.

Viele Systeme geraten in Schwierigkeiten, wenn sie diese beiden Ideen in dasselbe Rollenmodell zusammenfassen.

Ein geteilter Link mag betrieblich ähnlich wie ein Viewer-Konto aussehen, aber die Vertrauensannahmen sind unterschiedlich:

• geteilte Links sind leicht weiterzugeben
• geteilte Links sind dazu gedacht, widerrufbar zu sein
• geteilte Links sind normalerweise Prinzipale mit geringerer Sicherheit

Wenn dieser Prinzipal mit geringerer Sicherheit Management-Aktionen durchführen oder neue dauerhafte Identitäten erzeugen kann, ist die Freigabegrenze bereits gebrochen.

Das ist die eigentliche Lehre.

Wichtige Punkte

• öffentliche Freigabefunktionen sind Sicherheitsgrenzen
• Shared-Link-Prinzipale sollten keine gewöhnlichen Mitgliedschaftsverwaltungsfähigkeiten erben
• Mitgliederaufzählung aus einem öffentlichen Freigabekontext ist bereits sensibel
• unbefugte Einladung ist schlimmer, da sie echte dauerhafte Prinzipale erzeugt
• der Widerruf der ursprünglichen Freigabe reicht nicht aus, wenn das vom Angreifer erstellte Konto überlebt
• die Behandlung von öffentlichem Freigabezugriff als separaten Prinzipaltyp ist das sicherere Design

Abschließende Worte

Diese Schwachstelle handelte nicht davon, die Authentifizierung vollständig zu umgehen.

Es ging darum, zwei Vertrauensebenen zusammenzuführen, die getrennt hätten bleiben sollen.

In NocoDB sollte ein Shared-Base-Link temporären, widerrufbaren Zugriff auf gemeinsam genutzte Inhalte bieten. Stattdessen konnte er verwendet werden, um Mitglieder aufzulisten, einen echten Benutzer in die Base einzuladen und öffentlichen Freigabezugriff in dauerhafte authentifizierte Mitgliedschaft umzuwandeln, die den Widerruf der Freigabe überlebte.

Deshalb wurde dies zu CVE-2026-46552.