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.