#Homelab · 4 Min. Lesezeit · Tim Rinkel

DATEN-RAUB! Metabase-Lücke mit CVSS 10 reisst Framework und n8n auf — prüfe JETZT deine Instanz

DATEN-RAUB! Metabase-Lücke mit CVSS 10 reisst Framework und n8n auf — prüfe JETZT deine Instanz

Wenn du das BI-Tool Metabase selbst hostest, hör kurz auf zu scrollen: Eine Schwachstelle mit dem Höchstwert CVSS 10.0 wurde bereits als Zero-Day ausgenutzt — und die Liste der Opfer liest sich wie ein Who’s who der Tech-Szene. Der PC-Hersteller Framework, die Workflow-Plattform n8n und das KI-Tool Kilo Code haben in den letzten Tagen Datenabflüsse bestätigt; die jüngsten Updates stammen vom 11. August.

SO simpel ist der Angriff

Die Lücke — sie trägt bislang nicht einmal eine CVE-Nummer — erlaubt es einem nicht angemeldeten Angreifer, SQL direkt in die Metabase-Anwendungsdatenbank zu injizieren. Einfallstor ist der Endpunkt /api/session/reset_password. Wer durchkommt, macht sich selbst zum Administrator und kann dann: die Konfiguration ändern, gespeicherte Zugangsdaten aller verbundenen Datenbanken stehlen, sämtliche darüber erreichbaren Daten lesen und exportieren.

Metabase zufolge wurde zuerst die eigene Cloud angegriffen — betroffen sind aber genauso alle Self-Hosted-Versionen ab x.58. Gepatchte Releases stehen für alle Zweige bereit (x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 und x.63.5).

Die Opferliste wächst — DAS ist bisher bekannt

Bei Framework griffen die Angreifer Namen, E-Mail-Adressen, Anschriften, Telefonnummern und Login-IPs von Kunden ab — Zahlungs- und Bestelldaten blieben verschont. n8n meldet 136 abgeflossene Kundendatensätze, fünf davon mit bcrypt-gehashten Passwörtern von Cloud-Accounts; bei der Untersuchung stolperte das Team zusätzlich über einen Altfehler von 2023, durch den einige Passwörter im Klartext gespeichert worden waren. Bei Kilo Code erwischte es Slack-Tokens des hauseigenen Slackbots — der Angriff lief dort in einem Zeitfenster von nur vier Stunden am 2. August.

PRÜFE deine Logs — die Spuren sind eindeutig

Metabase-Chef Sameer Al-Sakran nennt ein klares Erkennungsmuster: ein POST /api/session/reset_password mit Status 400, direkt gefolgt von einem GET /api/user/current mit Status 200. Findest du diese Kombination in deinen Access-Logs, musst du von einer Kompromittierung ausgehen.

Dann gilt der volle Notfallplan: alle aktiven Sessions löschen (Tabelle core_session in der Anwendungsdatenbank leeren), API-Keys durchsehen und unbekannte entfernen, Admin-Konten auf Änderungen prüfen und — das ist der wichtigste Punkt — die Zugangsdaten aller in Metabase hinterlegten Datenbanken rotieren. Wer nicht sofort updaten kann, sollte den Endpunkt /api/session/reset_password per Reverse Proxy blockieren.

FAZIT: Dashboards sind Kronjuwelen-Verwalter

Der Fall zeigt einmal mehr, warum Analytics-Tools nie sorglos im offenen Netz stehen sollten: Metabase kennt die Zugangsdaten zu all deinen Datenbanken — wer es knackt, bekommt den Generalschlüssel. Schon die n8n-Lücke mit CVSS 10 im Mai und das Botnetz, das offene KI-Dienste abgrast, haben gezeigt, wie schnell exponierte Self-Hosting-Dienste gefunden werden. Pack deine internen Tools hinter VPN oder Reverse Proxy mit Auth — und patche Metabase heute, nicht morgen.

Häufige Fragen

Welche Metabase-Versionen sind betroffen?
Alle Versionen ab x.58 — sowohl Metabase Cloud als auch Self-Hosted (Open Source und Enterprise). Die Cloud wurde von Metabase bereits zwangsaktualisiert. Self-Hoster müssen selbst updaten: Abgesichert sind x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 und x.63.5 oder neuer. Ältere Zweige vor x.58 sind nach aktuellem Stand nicht betroffen.
Wie erkenne ich, ob meine Instanz kompromittiert wurde?
Durchsuche deine Access- oder Ingress-Logs nach einem POST auf /api/session/reset_password mit Status 400, unmittelbar gefolgt von einem GET auf /api/user/current mit Status 200. Genau dieses Muster nennt Metabase als Indikator für einen erfolgreichen Angriff. Prüfe zusätzlich Admin-Konten, API-Keys und die Query-Historie auf Aktivitäten, die du nicht zuordnen kannst.
Was muss ich nach dem Update noch tun?
Das Update allein reicht nicht, wenn der Endpunkt öffentlich erreichbar war: Lösche alle Zeilen der Tabelle core_session, um aktive Sitzungen zu beenden, entferne unbekannte API-Keys, prüfe Administrator-Konten und rotiere vor allem die Zugangsdaten aller verbundenen Datenbanken — genau diese Credentials konnten Angreifer auslesen.
Warum hat die Lücke keine CVE-Nummer?
Metabase hat die Schwachstelle bisher nur über ein GitHub-Security-Advisory mit CVSS-Bewertung 10.0 veröffentlicht, ohne eine CVE-ID zu beantragen. Das ändert nichts am Risiko — die Lücke wurde nachweislich aktiv ausgenutzt. Eine CVE-Zuweisung kann nachträglich erfolgen, sobald der Disclosure-Prozess abgeschlossen ist.
Gab es schon einmal so eine schwere Metabase-Lücke?
Ja — fast auf den Tag genau vor drei Jahren: CVE-2023-38646 (CVSS 9.8) erlaubte 2023 Remote-Code-Ausführung ohne Anmeldung. Der aktuelle Fall wiegt schwerer, weil er nicht nur theoretisch kritisch ist, sondern nachweislich für Datendiebstahl bei mehreren bekannten Unternehmen genutzt wurde.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert