SurrealDB: Mandantenübergreifender Zugriff durch authentifizierte Namespace- oder Datenbank-Benutzer

Zusammenfassung

SurrealDB-Versionen vor 3.3.0 prüfen nicht, ob der vom Aufrufer gewählte Namespace oder die gewählte Datenbank der Ebene entspricht, auf der sich der Benutzer authentifiziert hat. Ein Angreifer mit einem gültigen Konto auf Namespace- oder Datenbankebene in einem Mandanten kann über die Header Surreal-NS/Surreal-DB auf /sql oder über die RPC-Methode use einen anderen Mandanten auswählen. Dort kann er Zeilen lesen, erstellen, ändern und löschen sowie Werte von DEFINE PARAM auslesen, jedoch nur, soweit die PERMISSIONS der Tabelle dies erlauben. Der Hersteller stuft die Schwachstelle als kritisch ein; NVD bewertet sie mit 8.6 (CVSS 4.0).

Betroffen

• SurrealDB-Versionen vor 3.3.0 (laut Hersteller: jede betroffene Version v3.2.4 und älter)
• Relevant für Instanzen, die mehrere Mandanten mit Zugangsdaten auf Namespace- oder Datenbankebene betreiben
• Laut Hersteller sind Single-Tenant-Installationen und Aufrufer mit Root-Berechtigung nicht betroffen

Behoben in

• SurrealDB 3.3.0 und neuer
• Die Korrekturen sind in 3.3.0 standardmässig aktiviert
• Backports auf frühere Zweige: Unbekannt.

Umgehung

• Bis zum Update Zugangsdaten auf Namespace-, Datenbank- und Record-Ebene nur Parteien ausstellen, die allen Mandanten der Instanz vertrauen.
• Zur Isolation der Mandanten getrennte Deployments statt Namespace-/Datenbank-Grenzen verwenden.
• PERMISSIONS FULL durch eine PERMISSIONS-WHERE-Klausel ersetzen, die die Identität des Aufrufers prüft (zum Beispiel $auth). Dies reduziert das Risiko, stellt die Mandantengrenze aber nicht wieder her.
• Weitere konfigurationsbasierte Massnahmen: Unbekannt.

Ausnutzung

• Keine bekannte Ausnutzung in freier Wildbahn.
• Kein öffentlicher Proof of Concept gefunden.
• CISA SSVC: Ausnutzung keine, nicht automatisierbar, partielle technische Auswirkung.
• EPSS 0.00258 (geringe prognostizierte Wahrscheinlichkeit, kein Nachweis einer Ausnutzung).

Unsere Empfehlung

• Alle SurrealDB-Instanzen und deren Versionen inventarisieren.
• Jede Instanz unter 3.3.0 nach Prüfung der Release Notes des Herstellers auf 3.3.0 oder neuer aktualisieren.
• Bis dahin Zugangsdaten auf Namespace- und Datenbankebene nur Parteien geben, die allen Mandanten vertrauen, und den Netzwerkzugriff auf die Datenbank-Endpunkte einschränken.
• PERMISSIONS der Tabellen und Werte von DEFINE PARAM auf Mehrmandanten-Instanzen überprüfen.
• Protokolle auf ungewöhnliche Nutzung der Header Surreal-NS/Surreal-DB oder der RPC-Methode use überwachen.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• GitHub Security Advisory GHSA-w5v9-jc5f-5rmc github.com
• VulnCheck Advisory: SurrealDB before 3.3.0 Cross-Tenant Access www.vulncheck.com
• GitHub Security Advisory GHSA-vx2p-7hhm-wv62 (Surreal-NS/Surreal-DB headers with Basic authentication) github.com
• GitHub Security Advisory GHSA-2v9j-645m-pcrq (USE statement) github.com
• GitHub Security Advisory GHSA-3vw5-j55x-486h (RETURN FETCH for record users) github.com
• SurrealDB Release 3.3 surrealdb.com
• NVD record via Vulners vulners.com
• Positive Technologies PT-2026-110751 via Vulners vulners.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 08:42.