Japan: JPCERT warnt vor Datenlecks über API-Missbrauch und Metabase

In Japan sind innerhalb von rund zwei Wochen mehr als ein Dutzend bekannte Organisationen Opfer von Datenabflüssen geworden. Am Freitag, 09.10.2026, hat Digitalminister Masaaki Taira laut Financial Times und heise online eine Krisensitzung einberufen und von einem Notstand im Cyberraum gesprochen. Für deutsche Admins ist das mehr als eine Auslandsmeldung: Die japanische CERT-Stelle JPCERT/CC hat die Angriffsmuster so konkret beschrieben, dass sich die eigenen Systeme damit prüfen lassen. Der Kern liegt nicht in einer einzelnen Zero-Day-Lücke, sondern in missbrauchten Schnittstellen, Hilfssystemen und bekannten Schwachstellen.

Betroffen sind vor allem Betreiber von Web-Anwendungen mit Kundendaten, Mobile-App-Backends, internen Auswertungswerkzeugen wie Metabase und Anwendungsservern hinter einem öffentlichen Webserver. Wer nichts davon betreibt, ist nach heutigem Stand nicht direkt im Visier. Die Prüfung der eigenen API-Zugriffsregeln und der Metabase-Version ist trotzdem eine Sache von Stunden und sollte nicht bis zum nächsten Wartungsfenster liegen bleiben, sobald ein Metabase mit Internetzugang im Bestand ist. Der Hintergrund zur Metabase-Lücke steht in unserem Artikel zum Metabase-Zero-Day mit CVSS 10.0.

Was ist passiert?

Das JPCERT/CC hat seine Warnung JPCERT-AT-2026-0030 am 08.10.2026 veröffentlicht und am 09.10.2026 aktualisiert. Die Stelle nennt ihr Wissen selbst begrenzt und bruchstückhaft und betont, dass nicht jeder Vorfall dieselbe Methode nutzt. Neu im Update vom 09.10.2026 sind weitere verdächtige Quell-IP-Adressen und ein vierter Fall: Auf Anwendungsservern hinter öffentlichen Webservern wurden WAR-Dateien abgelegt, deren JSP-Datei als einfache Webshell arbeitet und Shell-Befehle aus einem Query-Parameter ausführt.

Die Zahlen stammen aus Veröffentlichungen der Betroffenen und von Medien. Laut The Hacker News meldete die Restaurantkette Yakiniku King 10.788.963 abgeflossene Datensätze aus dem Mitgliedersystem ihrer App. Park24 nannte rund 6,6 Millionen Konten des Carsharing-Dienstes Times Car, bei etwa 1,6 Millionen davon auch Ausweisdokumente wie Führerscheinbilder. Heise berichtet unter Berufung auf den Rundfunk NHK von mindestens 18 Fällen, die Financial Times von mindestens 20 Unternehmen. Wer dahintersteckt, ist offen. Beide Zahlen sind Medienangaben und keine Bestätigung einer einheitlichen Täterschaft.

Das Sicherheitsunternehmen Macnica hat öffentlich bekannte Fälle ausgewertet: 119 Vorfälle mit gestohlenen Personendaten über Web-Systeme in Japan bis zum 06.10.2026, nach 84 im ganzen Jahr 2025 und 62 im Jahr 2024. Von den 81 Fällen seit Juli ließ sich bei 65 aus den Mitteilungen keine Einbruchsmethode erkennen. Ähnliche Fälle gab es laut Macnica auch in 13 weiteren Ländern oder Regionen, darunter Südkorea (30), Frankreich (11) und Polen (8). Ob Japan das einzige Ziel ist, bleibt damit offen.

Wer ist betroffen?

Konkret betroffen sind Organisationen, die eines der vier von JPCERT/CC beschriebenen Muster bieten. Ein einzelnes Produkt oder eine einzelne Version gibt es nicht, mit einer Ausnahme: Metabase mit der Lücke CVE-2026-72898. Betroffen sind laut Metabase die Release-Linien 58 bis 63 unterhalb der Mindestversionen 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 und 0.63.5 (Open Source) beziehungsweise 1.58.24 bis 1.63.5 (Enterprise). Versionen unter 58 sind laut Hersteller nicht verwundbar. Metabase Cloud hat der Hersteller selbst abgesichert.

Nicht betroffen von der Metabase-Lücke sind Installationen, die nie öffentlich erreichbar waren und schon auf einer Mindestversion laufen. Das ändert nichts an den übrigen Mustern: Mobile-App-APIs und interne Verwaltungs-APIs gehören nicht zu Metabase und brauchen eine eigene Prüfung.

Wie kritisch ist das?

Für Metabase gilt die Lage als gesichert kritisch: CVSS 10.0, Angriff ohne Anmeldung über den Endpunkt /api/session/reset_password, Folge ist per SQL-Injection erlangter Administratorzugriff. Metabase bestätigt aktive Ausnutzung, die CISA führt die Lücke seit 11.08.2026 im KEV-Katalog. Diese Einordnung ist alt, neu ist der Bezug zur aktuellen Welle: JPCERT/CC verzeichnet Zugriffe, die ab Anfang August bis Anfang September von den genannten IP-Adressen ausgingen. Ob damit jeder der aktuellen Datenabflüsse in Japan erklärt wird, sagt das JPCERT/CC ausdrücklich nicht.

Die API-Muster sind technisch weniger spektakulär und gerade deshalb relevant. Sie bauen auf Konstruktionsfehlern auf: fehlende Zugriffsprüfung an nicht öffentlichen Endpunkten, zu großzügig ausgelieferte Daten, vergessene Schlüssel in der App. Dagegen hilft kein Patch, sondern nur ein Review. Nur relevant für Umgebungen mit Kundendaten hinter APIs, dort aber hoch zu priorisieren.

Fall laut JPCERT/CC	Angriffsmuster	Erste Gegenmaßnahme
A: Suche nach bekannten Lücken	Scans nach bekannten Schwachstellen und Verwaltungsfehlern, etwa offenen Konfigurations- und Backup-Dateien	Patchstand und öffentlich erreichbare Dateien prüfen
B: API-Missbrauch	Endpunkte und Schlüssel aus Apps extrahiert, interne APIs angegriffen, Blind-NoSQL-Injection, gestohlene API-Schlüssel	Zugriffsprüfung je Endpunkt, Rate Limits, Tokens rotieren
C: Metabase	SQL-Injection CVE-2026-72898 über die Passwort-Reset-Schnittstelle	Auf Mindestversion aktualisieren, Endpunkt sperren, Zugangsdaten rotieren
D: Webshell (neu am 09.10.)	WAR-Datei mit JSP-Webshell auf Anwendungsserver hinter dem Webserver	Anwendungsserver nach unbekannten WAR- und JSP-Dateien durchsuchen

Was sollten Admins jetzt tun?

• Inventar prüfen: Alle Metabase-Instanzen samt Version erfassen (Menü „Über Metabase“) und mit den Mindestversionen vergleichen. Gilt auch für Test- und Altinstanzen mit Zugang zu Produktivdatenbanken.
• Auf Metabase-Instanzen, die vor dem Update öffentlich erreichbar waren, laut Hersteller nach dem Upgrade alle Sitzungen widerrufen (Zeilen in core_session löschen), unbekannte API-Schlüssel entfernen, Administratorkonten prüfen und die Zugangsdaten der angebundenen Datenbanken rotieren.
• Wenn ein sofortiges Update nicht möglich ist: den Endpunkt /api/session/reset_password am Reverse Proxy oder an der WAF sperren und das Werkzeug aus dem öffentlichen Netz nehmen.
• Alle APIs inventarisieren, auch solche, die nur eine App oder ein Verwaltungswerkzeug anspricht, und je Endpunkt Authentifizierung, Autorisierung und erlaubte HTTP-Methoden prüfen.
• Rate Limits für Login, Passwort-Reset, SMS-Versand und Suchfunktionen setzen, API-Tokens mit kurzer Laufzeit und minimalen Rechten ausstellen und ein Verfahren zum schnellen Widerruf bereithalten.
• Logs nach den von JPCERT/CC genannten Merkmalen durchsuchen: die veröffentlichten Quell-IPs, die User-Agents curl/7.88.1 und python-requests sowie auffällige Fehlerreihen an API-Endpunkten. Die Liste kann auch legitime Zugriffe enthalten und ist nur ein Anhaltspunkt.
• Auf Anwendungsservern hinter öffentlichen Webservern nach unbekannten .war und .jsp Dateien suchen und die Erreichbarkeit dieser Server aus dem Internet prüfen.
• Nicht mehr benötigte personenbezogene Daten löschen und Verwaltungsfunktionen aus dem Internet nehmen, soweit nicht zwingend nötig.

Einordnung für Unternehmen

Die Welle in Japan zeigt ein Muster, das auch kleine und mittlere Unternehmen kennen sollten: Angreifer suchen breit, nicht gezielt. Laut Macnica trifft es Bibliothekskataloge, Sitzplatzreservierungen und Ticket-Rückerstattungen genauso wie Onlineshops. Wer irgendwo eine Web-Anwendung mit Personendaten betreibt, steht auf der Zielliste, unabhängig von Branche und Größe. Besonders gefährdet sind Systeme, die Admins „nur intern“ nennen, aber aus dem Internet erreichbar sind.

Die Folgen reichen über das betroffene Unternehmen hinaus. Japanische Banken sollen laut Berichten keine Führerscheine mehr als Identitätsnachweis bei der Kontoeröffnung akzeptieren, sondern nur noch Ausweise mit NFC-Chip. Das zeigt, wie gestohlene Ausweiskopien nachwirken. Aufbewahrung von Ausweisbildern und ein Löschkonzept sind deshalb kein Formalismus. Für den Fall eines Abflusses sollten Kontaktwege zu Kunden und eine Meldekette zur Datenschutzbehörde vorab festgelegt sein.

Passende Anleitungen auf S-EDV

• Metabase-Zero-Day mit CVSS 10.0: Hintergrund zur Lücke CVE-2026-72898 und zu den ersten Gegenmaßnahmen.
• WordPress REST API absichern: Beispiel, wie sich offene API-Endpunkte einschränken lassen.
• Logs zentralisieren mit Grafana Loki: Zugriffsprotokolle sammeln, um auffällige Anfragen zu finden.

Quellen

• JPCERT/CC: Warnung JPCERT-AT-2026-0030 zu den Zugriffen auf Organisationen in Japan (veröffentlicht 08.10.2026, aktualisiert 09.10.2026)
• The Hacker News: Bericht zur JPCERT/CC-Warnung vom 08.10.2026
• heise online: Japan reagiert auf Welle von Cyberangriffen (10.10.2026)
• Macnica Security Research Center: Auswertung der Web-Datenlecks (07.10.2026, japanisch)
• Metabase: Sicherheitshinweis GHSA-vwf4-m7j8-wcjf zu CVE-2026-72898
• Metabase: Sicherheitsupdate mit Mindestversionen
• CISA: Katalog bekannter ausgenutzter Schwachstellen (Eintrag CVE-2026-72898 vom 11.08.2026)