Die Metabase-Sicherheitslücke bekam den höchsten Risikowert, den die Skala kennt: CVSS 10 von 10.[1] Seit dem 3. August 2026 nutzen Angreifer sie aktiv aus. Der Notebook-Hersteller Framework musste bereits alle Kunden über einen Datenabfluss informieren.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Das Wichtigste in Kürze

  • Eine unauthentifizierte SQL-Injection in Metabase erlaubt die komplette Übernahme der Instanz, bewertet mit dem Höchstwert CVSS 10.
  • Die Angriffe laufen seit dem 3. August 2026, eine CVE-Nummer fehlt bislang, klassische Scanner erkennen die Lücke also nicht.
  • Beim Hersteller Framework flossen Namen, Adressen, Telefonnummern und Login-IP-Adressen sämtlicher Kunden ab, Zahlungsdaten blieben unberührt.
  • Betreiber sollten sofort patchen, den betroffenen Endpunkt sperren und alle Zugangsdaten rotieren.

Wie kapern Angreifer eine Analyse-Plattform?

Glasvitrine mit Karteikarten und aufstehendem Schlüssel mit Anhänger „Analyse-Zugang“
Angreifer exploitieren offenen API-Endpunkt ohne Authentifizierung, injizieren SQL-Code und erhalten Admin-Rechte über die gesamte Anwendung

Der Angriff beginnt an einer einzigen offenen Tür. Ohne Anmeldung schickt ein Angreifer präparierten Code an den Endpunkt /api/session/reset_password und schleust darüber eigene SQL-Befehle in die Datenbank der Anwendung ein. Danach ernennt er sich selbst zum Administrator und übernimmt die komplette Instanz.

Die eigentliche Gefahr steckt in der Rolle der Software. Eine Business-Intelligence-Plattform wie Metabase bündelt die Zugangsdaten zu jeder angeschlossenen Datenbank an einem Ort. Mit der Kontrolle über sie liest ein Angreifer nicht nur Diagramme, sondern erreicht die Rohdaten dahinter. Dasselbe Muster zeigte sich vor wenigen Tagen bei einer Lücke im Build-Server TeamCity, über die Angreifer die Kontrolle ohne Zugangsdaten erlangten.

Eine Analyseplattform sieht harmlos aus, hält aber die Schlüssel zu jeder angeschlossenen Datenbank. Genau deshalb gehört sie hinter dieselbe Mauer wie das Kernsystem, nicht davor.

— Markus Seyfferth, Chefredakteur Dr. Web

Warum trifft es ausgerechnet die Analyse-Schicht?

Framework bekam die Folgen als Erster öffentlich zu spüren. Metabase entdeckte den Angriff auf seine Cloud am 3. August 2026 und benachrichtigte den Hersteller am 6. August. Nach Prüfung der Protokolle bestätigte Framework, dass Namen, E-Mail-Adressen, Telefonnummern, Login-IP-Adressen sowie Rechnungs- und Lieferanschriften sämtlicher Kunden abgeflossen sind. Zahlungsdaten blieben unberührt.

Ein Muster zeichnet sich ab: Nicht das Kernsystem fällt, sondern die Nebenschicht, die still mitliest. Framework kündigte an, künftig genauer zu begrenzen, welche Datenbankspalten eine externe Analyseplattform überhaupt zu sehen bekommt. Ähnlich gelagerte Datenabflüsse trafen zuletzt einen Rüstungszulieferer über ein gekapertes Microsoft-365-Postfach und ruhende Konten bei NetEase.

Metabase-Sicherheitslücke im Überblick
Eine unauthentifizierte SQL-Injection, ausgenutzt seit Anfang August 2026
10,0
CVSS-Wert, die höchste Risikostufe der Skala
3. Aug
Beginn der aktiven Angriffe auf die Metabase-Cloud (2026)
0
vergebene CVE-Nummer, klassische Scanner erkennen die Lücke nicht

Bei Framework abgeflossen

Vollständige NamenE-Mail-AdressenTelefonnummernLogin-IP-AdressenRechnungsanschriftenLieferanschriftenFirmennamen

Sofortmaßnahmen für Betreiber

  1. Eine abgesicherte Version einspielen: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 oder 0.63.5.
  2. Bis zum Patch den Endpunkt /api/session/reset_password sperren.
  3. Alle aktiven Sitzungen widerrufen und die Datenbank-Zugangsdaten rotieren.
  4. Aktivitätsprotokolle auf fremde Admin-Konten und ungewöhnliche Abfragen prüfen.

Was müssen DACH-Betreiber jetzt tun?

Patchen allein genügt nicht. Für die Lücke wurde bislang keine CVE-Nummer vergeben, klassische Schwachstellen-Scanner schlagen also nicht an. Betreiber installieren eine der abgesicherten Versionen (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 oder 0.63.5), sperren notfalls vorab den verwundbaren Endpunkt und widerrufen anschließend alle Sitzungen samt der Datenbank-Zugangsdaten. Bei der Priorisierung solcher Fälle hilft ein Risiko-Score wie bei WP Triage.

Rechtlich läuft parallel eine Uhr. Sind personenbezogene Daten betroffen, verlangt Artikel 33 der DSGVO die Meldung an die Aufsichtsbehörde binnen 72 Stunden, bei hohem Risiko zusätzlich die Information der Betroffenen nach Artikel 34. Unternehmen unter den NIS-2-Pflichten treffen die Melde- und Härtungsvorgaben des BSI obendrein.

Cybersecurity bleibt damit Chefsache und keine reine IT-Fußnote. Ein sauberes Sicherheitsfundament heißt jetzt vor allem, jede extern angebundene Plattform auf eine einzige Frage zu prüfen: Wie viele Daten sieht sie, wie gut ist sie abgeschottet?

Quelle

[1] Metabase: „SQL injection using an unauthenticated endpoint leading to admin access“ (Security Advisory GHSA-vwf4-m7j8-wcjf)

Mehr Newshunger?

4,6 20 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?