Metabase-Zero-Day per SQL-Injection ausgenutzt: Framework und Tally bestätigen Datenabfluss

YuSMP Group Editorial Team Redaktionsteam, YuSMP Group

Die Kurzfassung

Was ist passiert?

Metabase bemerkte die Angriffe am 3. August 2026. Drei Tage später, am 6. August, informierte das Unternehmen betroffene Kunden, sperrte die bei den Angriffen genutzten API-Endpunkte und veröffentlichte gepatchte Releases. Die öffentliche Bekanntgabe folgte am 7. August.

Framework ging als erstes großes Opfer an die Öffentlichkeit. In einer E-Mail an alle Kunden vom 7. August erklärte das Unternehmen, Angreifer hätten über einen Drittanbieterdienst für Business Intelligence – Metabase – auf Kundendatensätze zugegriffen. Erbeutet wurden Namen, E-Mail-Adressen, Telefonnummern sowie Rechnungs- und Lieferadressen. Zahlungsdaten waren nicht betroffen.

Tally, Anbieter digitaler Formulare für Tausende Unternehmen, bestätigte einen separaten Vorfall, bei dem E-Mail-Adressen und gehashte Passwörter von Benutzerkonten offengelegt wurden; die Formulardaten der Kunden wurden nicht erreicht. Auch LexisNexis meldete, dass seine Metabase-API-Integration getroffen wurde; der Umfang ist noch nicht bestätigt.

Wie funktioniert die Schwachstelle?

Es handelt sich um eine SQL-Injection ohne Authentifizierung in der Anwendungsschicht von Metabase. Metabase speichert Verbindungsstrings, Zugangsdaten und Abfrageergebnisse für jede verwaltete Datenquelle. Wer SQL direkt in die Metabase-Datenbank einschleust – ohne sich vorher anzumelden –, kann sich zum Administrator machen, gespeicherte Datenbank-Zugangsdaten auslesen und von dort aus in jede angebundene Datenquelle vordringen.

Der mögliche Schadensradius ist groß. Produktive Metabase-Instanzen halten oft Zugangsdaten für mehrere Data Warehouses, Transaktionsdatenbanken und externe APIs. Eine Kompromittierung von Metabase kann daher weit mehr offenlegen als die Analysedaten in den Dashboards. Fragt Metabase Produktionsdatenbanken direkt ab, ist der gesamte Datenbestand betroffen. Genau deshalb sollten regelmäßige Sicherheitsaudits auch BI- und Analytics-Werkzeuge abdecken, nicht nur Anwendungsserver und APIs.

Eine CVE-Nummer wurde noch nicht vergeben. Der CVSS-Wert liegt bei 10.0 – dem Maximum – und spiegelt die Kombination aus fehlender Authentifizierung, vollständiger Datenexposition und Ausnutzbarkeit aus der Ferne wider.

Wie erkennt man eine Kompromittierung?

Metabase hat eine konkrete Log-Signatur des Angriffs benannt: ein POST-Request auf /api/session/reset_password mit HTTP 400, unmittelbar gefolgt von einem erfolgreichen GET-Request auf /api/user/current mit HTTP 200. Prüfen Sie Webserver- und Anwendungslogs auf dieses Muster. Finden Sie es, ist die Instanz als vollständig kompromittiert zu behandeln.

Vorgehen bei bestätigter Kompromittierung: alle in Metabase gespeicherten oder darüber erreichbaren Datenbank-Zugangsdaten und API-Schlüssel rotieren, prüfen, auf welche Datensätze und nachgelagerten Systeme die Instanz Zugriff hatte, und die Zugriffsprotokolle dieser Systeme zwischen dem 3. und 6. August auf ungewöhnliche Abfragen oder Datenexporte durchsuchen.

Was bedeutet das für Softwareteams in den USA und der EU?

Der Metabase-Vorfall folgt einem Muster, das 2026 immer wieder auftritt: Das schwächste Glied im Software-Stack ist oft nicht die eigene Anwendung, sondern die Betriebswerkzeuge von Drittanbietern rundherum. Metabase gilt als internes Analysewerkzeug und wird deshalb meist weniger streng geprüft als kundennahe Systeme – obwohl es Zugangsdaten zu denselben Datenbanken hält, die diese Systeme abfragen.

Für FinTech-, HealthTech- und E-Commerce-Teams ist das besonders heikel. Metabase-Instanzen sind in diesen Umgebungen oft mit Datenbanken verbunden, die Finanzdaten, personenbezogene Daten, Gesundheitsdaten oder Zahlungshistorien enthalten. Nach der DSGVO muss eine Datenpanne mit Daten von EU-Bürgern binnen 72 Stunden nach Kenntnis der zuständigen Aufsichtsbehörde gemeldet werden. Nach HIPAA lösen Verletzungen bei Gesundheitsdaten in den USA Meldepflichten gegenüber dem Department of Health and Human Services und gegebenenfalls gegenüber Betroffenen aus.

Die übergreifende Architekturlehre betrifft den Schadensradius. Ein Werkzeug, das Zugangsdaten über viele Datenquellen bündelt, wird zum lohnenden Ziel. Behandeln Sie Ihre Analytics- und BI-Schicht mit denselben Zugriffskontrollen, derselben Patch-Disziplin und derselben Audit-Abdeckung wie Ihre API-Schicht.

Was bedeutet das für den DACH-Markt?

Metabase ist als Open-Source-BI im deutschsprachigen Mittelstand und bei Start-ups verbreitet, weil es sich schnell selbst hosten lässt – oft auf einem einzelnen Server, den das Data-Team ohne Beteiligung der IT-Sicherheit betreibt. Genau diese Schatten-Instanzen sind jetzt das Risiko. Für deutsche Unternehmen gilt die 72-Stunden-Frist nach Art. 33 DSGVO gegenüber der Landesdatenschutzbehörde; in Österreich ist die Datenschutzbehörde zuständig. In der Schweiz verlangt das revidierte Datenschutzgesetz (revDSG) eine Meldung an den EDÖB so rasch als möglich, wenn ein hohes Risiko für Betroffene besteht.

Für Betreiber, die unter NIS2 fallen, kommt eine eigene Meldekette für erhebliche Sicherheitsvorfälle hinzu; in Deutschland ist das BSI die zentrale Anlaufstelle. Praktisch heißt das: Inventarisieren Sie jetzt alle Metabase-Instanzen im Unternehmen, auch die nicht offiziell gemeldeten, und dokumentieren Sie Patch-Zeitpunkt und Log-Prüfung – diese Nachweise brauchen Datenschutzbeauftragte und Auditoren im Ernstfall.

Was ist jetzt zu tun?

• Version ermitteln. In Metabase: Einstellungen → Admin → Troubleshooting → Version. Mit dem betroffenen Bereich abgleichen (jedes Release von 1.58 bis 0.63).
• Sofort patchen. Auf das korrigierte Release Ihrer Minor-Version aktualisieren: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 oder 0.63.5. Bei Metabase Cloud wurde der Fix automatisch eingespielt; prüfen Sie die in Ihrer Instanz angezeigte Version.
• Wenn Sie nicht sofort patchen können, nehmen Sie die Instanz vom Netz oder sperren Sie den externen Zugriff, bis das Update eingespielt ist. Eine ungepatchte, aus dem Internet erreichbare Metabase-Instanz ist ein akutes Risiko.
• Logs prüfen auf die oben beschriebene Angriffssignatur. Wird sie gefunden: Incident Response starten, Zugangsdaten rotieren, nachgelagerte Systeme prüfen.
• Gespeicherte Zugangsdaten vorsorglich rotieren, unabhängig von Log-Funden. Der Angriff lief mindestens drei Tage vor der Entdeckung; Rotation ist auch ohne Hinweise die richtige Vorsichtsmaßnahme.
• Netzwerk-Exposition von Metabase prüfen. BI-Werkzeuge sollten in den meisten Umgebungen nicht direkt aus dem Internet erreichbar sein. Ist Ihre Instanz es, beschränken Sie den Zugang auf VPN oder internes Netz.
• Für EU-Teams unter der DSGVO: Lagen in Ihrer Metabase-Instanz personenbezogene Daten von EU-Bürgern und finden Sie Hinweise auf Zugriffe, kann die 72-Stunden-Meldefrist gegenüber der Aufsichtsbehörde bereits ab Kenntnis laufen – dokumentieren Sie den Zeitpunkt.

Häufig gestellte Fragen