Metabase-Notfallpatch: SQL-Injection mit CVSS 10.0 wird aktiv ausgenutzt

Self-hosted Software im Blick behalten, bevor es brennt? Wir überwachen Schwachstellen für die von uns betriebenen Systeme und patchen im vereinbarten Fenster - siehe CVE-Monitoring und Managed Operations, oder direkt ein Erstgespräch vereinbaren.

Metabase hat am 6. August 2026 zwei kritische Schwachstellen geschlossen. Die schwerwiegendere trägt CVSS 10.0 und wird laut Hersteller aktiv ausgenutzt: Ein nicht authentifizierter Angreifer kann über den Endpunkt /api/session/reset_password SQL in die Anwendungsdatenbank einschleusen und sich damit Administratorrechte verschaffen (GHSA-vwf4-m7j8-wcjf).

Die Lücke wurde als Zero-Day ausgenutzt, bevor ein Patch existierte. Inzwischen liegen bestätigte Folgen vor: Der Laptop-Hersteller Framework und der Formularanbieter Tally haben Datenabflüsse eingeräumt.

Zwei Dinge machen den Fall über Metabase hinaus interessant. Erstens: Es ist „nur" eine SQL-Injection und trotzdem der Höchstwert. Zweitens: Bei Veröffentlichung gab es keine CVE-Nummer, sie kam erst vier Tage später - wer sein Schwachstellenmanagement allein auf CVE-Feeds stützt, sieht diese Lücke gerade nicht.

Aktualisiert am 9. August 2026 um die bestätigten Datenabflüsse, das Erkennungsmuster aus den Zugriffsprotokollen und den inzwischen geklärten Status von Metabase Cloud.

Inhaltsverzeichnis

• Was genau passiert ist
• Was tatsächlich abgeflossen ist
• Warum eine SQL-Injection CVSS 10.0 bekommt
• Betroffene und gepatchte Versionen
• Sofortmaßnahmen
• Kompromittierung erkennen
• Nacharbeit nach dem Update
• Die Lücke ohne CVE - ein blinder Fleck im Monitoring
• Was das für Analytics-Werkzeuge grundsätzlich heißt
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was genau passiert ist

Metabase hat am 6. August 2026 zwei Advisories veröffentlicht. Beide sind SQL-Injection in die Anwendungsdatenbank von Metabase, beide führen zu Administratorzugriff - sie unterscheiden sich in der Voraussetzung.

Der Unterschied im Vektor ist genau ein Buchstabe: UI:N gegen UI:R. Die erste Lücke braucht keinerlei Zutun - kein Klick, kein Login, keine Vorbedingung. Für die zweite genügt dem Angreifer die UUID eines öffentlichen Links; öffentliches Teilen ist in Metabase standardmäßig aktiviert.

Wichtig zur Einordnung: Dies ist keine Remote Code Execution. Es wird kein Code auf dem Server ausgeführt. Das macht die Sache nicht harmloser, wie der nächste Abschnitt zeigt - aber wer nach RCE-Signaturen sucht, sucht am falschen Muster.

Was tatsächlich abgeflossen ist

Der Angriff fand am 3. August 2026 statt, drei Tage vor dem Patch. Metabase benachrichtigte betroffene Kunden am 6. August, die Fälle wurden am 7. August öffentlich.

Eine Unterscheidung, die in vielen Berichten untergeht: Die bestätigten Vorfälle betreffen Metabase Cloud. Framework betrieb eine Cloud-Instanz, und Metabase hat den Angriff auf der eigenen Plattform bemerkt. Selbst betriebene Instanzen sind verwundbar, aber ein Angriff auf eine konkrete Self-Hosting-Installation ist bislang nicht öffentlich dokumentiert.

Für Self-Hosting-Betreiber ändert das nichts an der Dringlichkeit, im Gegenteil: Cloud-Instanzen hat der Hersteller nach eigenen Angaben bereits aktualisiert. Wer selbst betreibt, muss selbst handeln - und weiß ohne Protokollauswertung nicht, ob er betroffen war.

Warum eine SQL-Injection CVSS 10.0 bekommt

Der entscheidende Teil des Vektors ist S:C - Scope Changed. Er besagt, dass der Schaden die Grenze der verwundbaren Komponente überschreitet.

Genau das ist bei einem Business-Intelligence-Werkzeug der Fall. Metabase ist kein System, das eigene Daten hält. Es ist ein System, das Zugangsdaten zu fremden Daten hält: PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, das Data Warehouse. Wer Metabase-Administrator wird, liest anschließend die hinterlegten Verbindungen aus.

Die Rechnung ist damit nicht „ein kompromittiertes Analytics-Tool", sondern „ein kompromittierter Zugang zu jeder angebundenen Datenquelle". Der Hersteller nennt in der Folgenabschätzung ausdrücklich das Auslesen gespeicherter Datenbank-Zugangsdaten und den Datenabfluss über die verbundenen Systeme.

Das ist der Grund, warum eine Lücke ohne Codeausführung beim Höchstwert landet - und der Grund, warum das Update allein nicht reicht.

Betroffene und gepatchte Versionen

Metabase pflegt mehrere Zweige parallel. Betroffen sind:

Die Tabelle zeigt den weiteren der beiden Bereiche, also die Frage „bin ich von einer der beiden Lücken betroffen?". Die aktiv ausgenutzte 10.0er-Lücke reicht jeweils eine Punktversion weniger weit: GitHub führt sie als >= x.58.0, < x.58.23 bis >= x.63.0, < x.63.3, betroffen sind dort also Stände bis x.58.22 beziehungsweise x.63.2. Wer auf x.63.3 oder x.63.4 steht, ist von der 10.0er-Lücke nicht mehr betroffen, von der zweiten aber sehr wohl - in beiden Fällen behebt x.63.5 das Problem. Wer eine ältere Hauptversion als x.58 betreibt, muss zuerst auf einen der gepflegten Zweige, bevor der Patch greift.

Prüfen lässt sich die laufende Version im Metabase-Dashboard unter Einstellungen oder direkt am Container-Tag.

Nachtrag vom 12. Oktober 2026: Am 11. August 2026 hat Metabase ein weiteres kritisches Advisory nachgeschoben: GHSA-r495-55cx-fjh7 bündelt zusätzliche SQL-Injection-Härtungen, vollständigere Berechtigungsprüfungen, Rate Limiting für Login und Passwort-Zurücksetzung sowie Korrekturen an der Netzwerk-Exposition. Die oben genannten Patchstände reichen dafür nicht. Gepatcht sind erst x.58.28, x.59.25, x.60.21, x.61.15, x.62.13 und x.63.10. Aktuell sind v0.64.1 vom 7. Oktober 2026 sowie v0.63.19 und v0.58.35 vom 1. Oktober 2026; die Zweige x.59 bis x.62 haben ihr letztes Update am 1. September 2026 erhalten. Wer noch auf einem der Notfall-Patchstände vom 6. August steht, sollte direkt auf den aktuellen Stand seines Zweigs oder auf x.63/x.64 gehen.

Sofortmaßnahmen

Erste Wahl bleibt das Update. Wo das nicht binnen Stunden geht, nennt der Hersteller Übergangsmaßnahmen:

• Für die unauthentifizierte Lücke: den Endpunkt /api/session/reset_password netzseitig sperren - im Reverse Proxy, in der Web Application Firewall oder in der Ingress-Regel. Das deaktiviert die Passwort-Zurücksetzung, was in Umgebungen mit SSO ohnehin kein Verlust ist.
• Für die zweite Lücke: öffentliches Teilen abschalten oder zumindest alle öffentlichen Links zurückziehen, die Field-Filter-Parameter enthalten.

Beides sind Notnägel. Sie schließen einen bekannten Weg, nicht die Schwachstelle.

Der wirksamste Schutz ist ohnehin struktureller Art: Ein Analytics-Werkzeug gehört nicht ins offene Internet. Erreichbarkeit ausschließlich über identitätsbasierten Fernzugriff statt über einen öffentlichen Port hätte beide Angriffswege von vornherein ins Leere laufen lassen.

Kompromittierung erkennen

Metabase nennt ein konkretes Muster, nach dem sich in den Zugriffsprotokollen suchen lässt:

POST /api/session/reset_password   → 400
GET  /api/user/current             → 200

Ein Aufruf des Passwort-Zurücksetzen-Endpunkts, der scheinbar mit einem Fehler endet, unmittelbar gefolgt von einem erfolgreichen Abruf des aktuellen Nutzers. Der erste Aufruf schlägt nur nach außen fehl; die Injektion hat da bereits gewirkt, und der zweite Aufruf zeigt die gültige Sitzung.

Das ist ein belastbarer Ansatzpunkt, weil er sich in jedem Reverse Proxy und jedem Ingress-Log wiederfinden lässt, ohne dass Metabase selbst etwas protokollieren muss. Der relevante Zeitraum beginnt spätestens am 3. August 2026.

Wer seine Protokolle nicht so weit zurück vorhält, kann diese Frage nicht beantworten und sollte die Nacharbeit im nächsten Abschnitt vollständig abarbeiten, statt auf einen Negativbefund zu hoffen.

Nacharbeit nach dem Update

Für die aktiv ausgenutzte Lücke reicht das Einspielen des Patches ausdrücklich nicht. Wer eine erreichbare Instanz betrieben hat, muss davon ausgehen, dass ein Zugriff stattgefunden haben kann. Der Hersteller nennt fünf Schritte:

1. Alle Sitzungen löschen - Einträge in der Tabelle core_session entfernen, damit übernommene Sitzungen ungültig werden
2. API-Schlüssel prüfen und alles widerrufen, was nicht zweifelsfrei bekannt ist
3. Administratorkonten durchsehen - neu angelegte Konten und geänderte Rollen sind das erste Zeichen
4. Datenbank-Zugangsdaten rotieren - alle, die in Metabase hinterlegt sind
5. Zugriffsprotokolle der angebundenen Systeme auswerten und die Aktivitätshistorie in Metabase prüfen

Punkt 4 ist der aufwendigste und der wichtigste. Wenn die hinterlegten Zugangsdaten abgeflossen sind, hilft ein gepatchtes Metabase nichts - der Angreifer spricht dann direkt mit der Datenbank.

Punkt 5 ist der, an dem die meisten scheitern. Wer keine Protokolle vorhält oder sie nicht auswerten kann, kann die Frage „ist etwas passiert?" nicht beantworten - und muss im Zweifel vom schlechteren Fall ausgehen.

Die Lücke ohne CVE - ein blinder Fleck im Monitoring

Nachtrag vom 31. August 2026: Die schwerwiegendere der beiden Lücken hat inzwischen eine Kennung. Sie wird als CVE-2026-72898 geführt, mit CVSS 10.0 bestätigt, und die CISA hat sie am 11. August 2026 in den Katalog bekannter ausgenutzter Schwachstellen aufgenommen, mit Behebungsfrist zum 14. August. Der Abschnitt unten beschreibt den Zustand zum Zeitpunkt des Angriffs; die Lücke im Monitoring ist damit nicht verschwunden, sondern erstmals messbar geworden.

Nachtrag vom 12. Oktober 2026: Korrektur zum vorigen Nachtrag: Am 10. August 2026 wurden alle drei Advisories vom 6. August mit CVE-Nummern in der NVD veröffentlicht, nicht nur die schwerwiegendere. Die Dashboard-Lücke GHSA-r8h2-qpfx-mx59 läuft als CVE-2026-72899, das mittelschwere Advisory GHSA-8hmm-hrhg-ppqp als CVE-2026-72900. Im KEV-Katalog steht weiterhin nur CVE-2026-72898. Das Härtungs-Advisory vom 11. August trägt bis heute keine CVE-Nummer.

Zwischen Advisory und CVE-Nummer lagen also vier Tage. Wer sein Schwachstellenmanagement allein auf CVE-Feeds stützt, hatte in dieser Zeit keinen Hinweis auf eine Lücke, die zu diesem Zeitpunkt bereits ausgenutzt wurde.

Zum Zeitpunkt der Veröffentlichung dieses Beitrags trugen beide Advisories keine CVE-Nummer. Metabase hatte sie als GitHub Security Advisory veröffentlicht; eine Zuweisung war noch nicht erfolgt.

Das ist nicht ungewöhnlich, hat aber praktische Folgen: Ein Schwachstellenscanner, der gegen die National Vulnerability Database abgleicht, meldete zu diesen Lücken nichts - obwohl eine davon aktiv ausgenutzt wurde.

Belastbares Monitoring für selbst gehostete Software zieht deshalb mehrere Quellen zusammen: CVE und NVD, aber auch die GitHub Security Advisories der eingesetzten Projekte, deren Release Notes und die Hersteller-Announcements. Wie wir das aufsetzen, steht in CVE-Monitoring für selbst gehostete Software.

Was das für Analytics-Werkzeuge grundsätzlich heißt

Der Fall Metabase ist kein Einzelfall, sondern ein Muster. Business-Intelligence-Werkzeuge, ETL-Strecken und Dashboard-Plattformen haben alle dieselbe Eigenschaft: Sie sind Zugangsdaten-Tresore. Ihre Aufgabe besteht darin, sich mit möglichst vielen Datenquellen zu verbinden.

Daraus folgen drei Regeln, die unabhängig vom Produkt gelten:

Nicht öffentlich erreichbar. Ein BI-Werkzeug hat keinen Grund, aus dem offenen Internet erreichbar zu sein. Zugriff über identitätsbasierten Fernzugriff mit Mehrfaktorauthentifizierung kostet wenig und nimmt einer ganzen Klasse von Angriffen die Grundlage.

Getrennte Datenbankbenutzer mit Lesezugriff. Wenn Metabase mit einem Konto verbunden ist, das nur lesen darf und nur die benötigten Schemata sieht, ist ein kompromittiertes Metabase ein Datenleck - aber keine Übernahme des Data Warehouse.

Zugangsdaten rotierbar halten. Der fünfte Nacharbeitsschritt oben ist nur dann in Stunden statt Tagen erledigt, wenn vorher jemand aufgeschrieben hat, welche Zugangsdaten wo hinterlegt sind.

Unser Vorgehen bei WZ-IT

Für die von uns betriebenen Systeme überwachen wir Schwachstellen nicht nur über CVE-Feeds, sondern über die Advisory-Kanäle der eingesetzten Projekte - genau deshalb, weil Fälle wie dieser ohne CVE-Nummer auflaufen. Kritische Meldungen bewerten wir gegen den tatsächlichen Bestand: Welche Version läuft wo, ist die Instanz überhaupt erreichbar, und greift eine der Übergangsmaßnahmen.

Beim Einrichten selbst gehosteter Anwendungen setzen wir die drei Punkte aus dem vorigen Abschnitt als Standard: kein öffentlicher Zugang, getrennte Datenbankbenutzer mit dem geringstmöglichen Recht, dokumentierte Zugangsdaten. Das ist kein Mehraufwand im Betrieb, sondern der Unterschied zwischen einem Patch-Wochenende und einer Meldung nach NIS2.

Wenn Sie nicht sicher sind, wie Ihre bestehende Instanz dasteht: Der Server-Audit prüft Erreichbarkeit, Zugänge, Aktualisierungsstand und Wiederherstellbarkeit an einer Linux-Instanz zum Festpreis. Für den laufenden Betrieb ist CVE-Monitoring der passende Baustein.

Weiterführende Guides

• CVE-Monitoring für selbst gehostete Software - wie Schwachstellenmanagement ohne eigenes Security-Team funktioniert
• cPanel CVE-2026-41940 - derselbe Mechanismus, anderes Produkt
• OPNsense 26.1.8 - Patch-Management am Perimeter
• Linux-Kernel-Schwachstellen 2026 - warum Patch-Management Chefsache ist
• Managed Open Source - Betrieb quelloffener Anwendungen mit Wartungsfenster
• Compliance und NIS2 - Meldepflichten und was sie voraussetzen

Metabase im Einsatz und unsicher, ob die Instanz sauber ist? Wir prüfen Version, Erreichbarkeit und Zugriffsspuren, spielen den Patch ein und arbeiten die Nacharbeit ab - kurz sprechen oder direkt zum Server-Audit.

Quellen

• GHSA-vwf4-m7j8-wcjf: SQL injection using an unauthenticated endpoint leading to admin access
• GHSA-r8h2-qpfx-mx59: SQL injection using a publicly shared dashboard leading to admin access
• GHSA-r495-55cx-fjh7: Multiple vulnerabilities across query validation, permissions, and network exposure
• NVD: CVE-2026-72898
• NVD: CVE-2026-72899
• Metabase: Releases auf GitHub
• Metabase: Übersicht aller Security Advisories
• Metabase: Security update available - Please upgrade now
• heise online: Metabase-Zero-Day - Datenleck beim Laptop-Hersteller Framework
• BleepingComputer: Metabase SQLi zero-day exploited in customer data-theft attacks
• FIRST: CVSS v3.1 Specification Document (Scope-Metrik)
• BSI: NIS-2 und Meldepflichten für Unternehmen