Metabase CVSS 10 SQL Injection Zero-Day: Admin-Zugriff

Der Metabase CVSS 10 SQL Injection Zero-Day macht aus einem selbst gehosteten Analyse-Dashboard einen Generalschlüssel für jede angebundene Datenbank. Die aktive Ausnutzung begann am 3. August 2026, zwei namentlich bekannte Opfer — Framework und Tally — haben bereits den Diebstahl von Kundendaten bestätigt. Wer Metabase für internes Reporting betreibt, sollte diese Lücke nicht als „irgendwann patchen“ einstufen.

Was ist passiert

Metabase, die weit verbreitete Open-Source-Business-Intelligence-Plattform, hat eine unauthentifizierte SQL-Injection-Schwachstelle im Endpunkt POST /api/session/reset_password offengelegt, geführt als GHSA-vwf4-m7j8-wcjf mit einem maximalen CVSS-Wert von 10.0. Es wurde bislang keine CVE-Nummer vergeben — die Lücke taucht also weder in gängigen CVE-Datenbanken noch im CISA-KEV-Katalog auf. Darauf sollte man nicht warten, bevor man handelt.

Ein Angreifer ohne jegliche Zugangsdaten kann über den verwundbaren Endpunkt beliebigen SQL-Code in die Anwendungsdatenbank von Metabase einschleusen. Von dort eskaliert der Angreifer zu vollen Metabase-Administratorrechten und kann Daten lesen oder exportieren — inklusive der gespeicherten Zugangsdaten — für jede externe Datenbank, die Metabase abfragt. Betroffen sind Metabase Open Source Versionen 0.58.x bis 0.63.x sowie die entsprechenden Enterprise-/Pro-Zweige ab 1.58.x. Zuerst betroffen war die Metabase-Cloud-Infrastruktur; die Ausnutzung begann um den 3. August 2026.

Gepatchte Versionen sind 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 und 0.63.5 für Open Source (Enterprise-Builds tragen eine um eine Hauptversionsnummer höhere Kennung). Framework, Hersteller modularer, reparierbarer Laptops, und der Business-Software-Anbieter Tally haben beide bestätigt, dass Kundendaten — Namen, E-Mail-Adressen, Telefonnummern und Anschriften — über kompromittierte, mit ihren Kundendatenbanken verbundene Metabase-Instanzen gestohlen wurden.

Warum das wichtig ist

Business-Intelligence-Tools wie Metabase werden häufig mit dauerhaften, hochprivilegierten Verbindungen zu Produktionsdatenbanken betrieben — Kundendaten, Abrechnungssysteme, Personaldaten —, weil genau dieser Zugriff den Zweck des Tools ausmacht. Dieselbe Berechtigung macht eine kompromittierte BI-Instanz katastrophal: Der Angreifer muss die Datenbank nicht direkt angreifen, es reicht, das davorgeschaltete Dashboard zu knacken. In vielen Organisationen werden selbst gehostete Analyse-Tools von einem Daten- oder BI-Team bereitgestellt — außerhalb des formalen Schwachstellenmanagements, das „richtige“ Infrastruktur abdeckt. Genau diese Governance-Lücke legt der Vorfall offen.

Für den deutschen Mittelstand macht die Attraktivität von Metabase als kostenlose, selbst gehostete Alternative zu Tableau oder Power BI das Tool gerade in dem Marktsegment verbreitet, das am seltensten dedizierte Application-Security-Abdeckung für interne Tools hat. Unter NIS2 und DSGVO wird ein Datenschutzvorfall über ein angebundenes Analyse-Tool wie jeder andere Datenschutzvorfall behandelt — die Meldefrist beginnt in dem Moment, in dem personenbezogene Daten nachweislich offengelegt wurden, unabhängig davon, welches System den Einstiegspunkt bildete.

Was Sie jetzt tun sollten

1. Sofort auf die gepatchte Version des jeweiligen Zweigs aktualisieren: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 oder 0.63.5 (Open Source) beziehungsweise den entsprechenden Enterprise-/Pro-Build.
2. Falls ein sofortiges Patchen nicht möglich ist: Den Endpunkt /api/session/reset_password als Übergangsmaßnahme am Reverse Proxy oder in der WAF blockieren.
3. Prüfen, ob Sie betroffen sind: Metabase-Admin-Konten auf unbekannte Einträge kontrollieren und Anwendungslogs seit dem 3. August 2026 auf ungewöhnlichen POST-Traffic zum Reset-Password-Endpunkt durchsuchen.
4. Alle Zugangsdaten rotieren, die Metabase für verbundene Datenbanken gespeichert hatte — unabhängig davon, ob ein konkreter Kompromittierungsnachweis vorliegt. Die Zugangsdaten galten bereits als offengelegt, sobald ein Angreifer Admin-Zugriff erlangte, nicht erst bei nachweislichem Datenexport.

DIESEC Einschätzung

Dieses Muster sehen wir regelmäßig in Mittelstandsumgebungen: Ein selbst gehostetes Analyse- oder Reporting-Tool wird von der Person eingerichtet, die am schnellsten ein Dashboard brauchte, an zwei oder drei Produktionsdatenbanken angebunden, der Einfachheit halber — und taucht danach auf keiner Patch-Management-Liste mehr auf, weil es „ja nur ein Reporting-Tool“ ist. Dieser Metabase CVSS 10 SQL Injection Zero-Day-Fall zeigt unmittelbar, warum diese Einordnung falsch ist: Die Berechtigungen des Tools sind die Angriffsfläche, nicht seine Funktion.

Nicht sicher, ob Ihre internen BI- oder Reporting-Tools eine solche unkontrollierte Datenbankanbindung haben? Kontaktieren Sie DIESEC für eine schnelle Bestandsaufnahme Ihrer Drittanbieter-Anwendungen und eine Prüfung auf Zugangsdaten-Exposition.

Quellen: The Hacker News | BleepingComputer
Veröffentlicht: 2026-08-11 | Kategorie: Tägliche News | ~4 Min. Lesezeit