ArcadeDB: Drei kritische Lücken öffnen den Weg zu Admin-Rechten und ungeschützten Datenbefehlen

Kurzfassung

ArcadeDB muss vor der Version 26.8.1 gleich drei kritische Sicherheitslücken schließen. Zwei davon betreffen die Rechteprüfung bei JavaScript-basierten Befehlen, eine dritte den MongoDB-Wire-Protocol-Teil des Produkts. Wer ArcadeDB produktiv betreibt, sollte den Update-Stand jetzt prüfen. Für DACH-Unternehmen ist das besonders relevant, wenn die Datenbank intern erreichbar ist oder Entwickler Zugriff auf die Command-API haben.

Was ist passiert?

Die gemeldeten Schwachstellen drehen sich um denselben Kernfehler: ArcadeDB übergibt den authentifizierten Benutzer in bestimmten Ausführungspfaden nicht sauber an die Threads, die Befehle verarbeiten. Dadurch fällt die Sicherheitsprüfung an entscheidender Stelle aus. Das Ergebnis ist unschön. Ein Nutzer mit geringen Rechten kann unter Umständen JavaScript ausführen und sich bis zum Server-Administrator hochziehen.

Betroffen sind drei Fälle: CVE-2026-75843, CVE-2026-75851 und CVE-2026-75852. Die ersten beiden Lücken erlauben eine Rechteausweitung über JavaScript-gestützte Befehle. Die dritte betrifft den MongoDB-kompatiblen Datenpfad und ist noch heikler, weil dort laut Beschreibung sogar unauthentifizierte Angriffe möglich sind.

Technische Details

Bei CVE-2026-75843 bindet ArcadeDB den angemeldeten Principal im gRPC-Transaction-Pfad nicht korrekt an den Thread. Ein authentifizierter Leser kann dadurch JavaScript-Befehle ausführen, ohne dass die Scripting-Berechtigungen greifen. Laut Beschreibung lässt sich über executeCommand mit einer Transaktions-ID sogar Code ausführen, der serverweite Administrator-Konten anlegt. Das ist eine vollständige Kompromittierung der Instanz.

CVE-2026-75851 betrifft den Server in com.arcadedb:arcadedb-server bis einschließlich 26.7.3. Hier landet ein HTTP-Command mit awaitResponse:false auf einem asynchronen Worker-Thread, dem kein Benutzerkontext zugeordnet ist. Die Folge ist dieselbe Schwäche in der Rechteprüfung. Ein Nutzer mit Leserechten für genau eine Datenbank kann über /api/v1/command mit language=js Code mit vollem Host-Zugriff ausführen. Auch hier ist das Ziel klar: ein Administrator-Konto auf Serverebene anlegen und die Kontrolle übernehmen.

CVE-2026-75852 sitzt im MongoDB-Wire-Protocol-Plugin. ArcadeDB vor 26.8.1 erzwingt dort keine SASL-Authentifizierung für Datenbefehle. Wer Port 27017 erreicht, kann ohne Zugangsdaten insert, find, update, delete und create gegen beliebige Datenbanken absetzen. Das ist kein Randproblem. Es öffnet den Datenpfad direkt nach außen, falls der Port erreichbar ist.

Wer ist betroffen?

Betroffen sind alle Installationen von ArcadeDB vor 26.8.1, wobei die einzelnen Lücken unterschiedliche Angriffswege haben. CVE-2026-75851 nennt ausdrücklich Versionen 26.7.3 und älter. Für CVE-2026-75843 und CVE-2026-75852 nennt die Quelle nur den Bereich vor 26.8.1. Ob ältere oder parallele Build-Varianten anders reagieren, bleibt offen.

Für Unternehmen im DACH-Raum ist das vor allem dann kritisch, wenn ArcadeDB als interne Backend-Datenbank läuft, Skriptbefehle annimmt oder der MongoDB-Port 27017 aus dem Netz erreichbar ist. In solchen Umgebungen reicht oft schon ein schwaches Benutzerkonto oder ein falsch segmentiertes Netz, damit aus einem Leserechte-Konto ein Server-Admin wird. Für Privatnutzer ist das nur relevant, wenn sie ArcadeDB überhaupt selbst betreiben. Als Endkundenprodukt spielt die Software kaum eine Rolle.

Empfohlene Maßnahmen

Erstens: sofort auf ArcadeDB 26.8.1 oder eine vom Hersteller freigegebene neuere Version aktualisieren. Das ist die eigentliche Behebung. Alles andere ist nur Schadensbegrenzung.

Zweitens: den Zugriff auf /api/v1/command und gRPC strikt auf vertrauenswürdige Netze begrenzen. Wer diese Schnittstellen aus dem internen Netz heraus offen lässt, macht es Angreifern unnötig leicht. Prüfen Sie auch, ob awaitResponse:false wirklich gebraucht wird. Wenn nicht, schalten Sie den Pfad ab oder drosseln Sie ihn.

Drittens: Port 27017 nur dann freigeben, wenn der MongoDB-Wire-Protocol-Modus tatsächlich gebraucht wird. Falls ja, muss die SASL-Authentifizierung erzwungen und der Zugang zusätzlich per Firewall eingeschränkt werden. Viertens: vorhandene ArcadeDB-Logs auf auffällige Command-Aufrufe, neue Administrator-Konten und ungewöhnliche JavaScript-Ausführungen prüfen. Wer einen Kompromiss vermutet, sollte die Instanz isolieren und nicht nur patchen.

Einschätzung von CyberSecurity-News.de

Die Lage ist ernst. Drei kritische Lücken in derselben Produktlinie, zwei davon mit klarer Admin-Eskalation, eine mit offenem unauthentifiziertem Datenzugriff: Das ist kein kosmetischer Bug, sondern ein handfester Vertrauensbruch in die Zugriffslogik. Besonders unschön ist, dass die Fehler ausgerechnet in Thread- und Kontextübergaben stecken. Genau dort darf eine Datenbank nie schlampen.

Für Betreiber zählt jetzt Pragmatismus. Patchen, Angriffsflächen schließen, Protokollzugänge prüfen. Die Meldung ist nicht wegen eines großen Exploits dramatisch, sondern weil die Auswirkungen unmittelbar und tief sind. Wer ArcadeDB produktiv nutzt, sollte die Lücken nicht als theoretisch abtun. Die beschriebenen Angriffspfade sind kurz genug, um in realen Umgebungen schnell auszunutzen zu sein.

Fazit

ArcadeDB vor 26.8.1 enthält mit CVE-2026-75843, CVE-2026-75851 und CVE-2026-75852 drei kritische Schwachstellen mit hoher praktischer Relevanz. Zwei Fehler hebeln die Rechteprüfung bei JavaScript-Befehlen aus, die dritte Lücke öffnet den MongoDB-Datenpfad ohne Authentifizierung. Wer die Software einsetzt, sollte den Update-Stand sofort prüfen und exponierte Schnittstellen härten. Für die meisten Leser ist das nur dann ein Thema, wenn ArcadeDB wirklich im eigenen Bestand läuft. Dann aber mit Priorität eins.

Quellenangabe

Weiterführende Quelle: NVD zu CVE-2026-75843. Die hier zusammengefassten Angaben zu CVE-2026-75843, CVE-2026-75851 und CVE-2026-75852 stammen aus den NVD-Einträgen.