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).

Zwei Dinge machen diesen Fall über Metabase hinaus interessant. Erstens: Es ist „nur" eine SQL-Injection und trotzdem der Höchstwert. Zweitens: Es gibt keine CVE-Nummer - wer sein Schwachstellenmanagement allein auf CVE-Feeds stützt, sieht diese Lücke gerade nicht.

Inhaltsverzeichnis

• Was genau passiert ist
• Warum eine SQL-Injection CVSS 10.0 bekommt
• Betroffene und gepatchte Versionen
• Sofortmaßnahmen
• 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.

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:

Für die 10.0er-Lücke endet der betroffene Bereich in x.63 bei x.63.3, für die zweite bei x.63.4 - 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.

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.

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

Beide Advisories tragen keine CVE-Nummer. Metabase hat sie als GitHub Security Advisory veröffentlicht; eine Zuweisung ist bislang nicht erfolgt.

Das ist nicht ungewöhnlich, hat aber praktische Folgen: Ein Schwachstellenscanner, der gegen die National Vulnerability Database abgleicht, meldet zu diesen Lücken nichts - obwohl eine davon aktiv ausgenutzt wird. Wer sein Schwachstellenmanagement allein auf CVE-Feeds stützt, hat hier einen blinden Fleck von möglicherweise mehreren Tagen.

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
• Metabase: Übersicht aller Security Advisories
• FIRST: CVSS v3.1 Specification Document (Scope-Metrik)
• BSI: NIS-2 und Meldepflichten für Unternehmen