Datenleck-Welle in Japan: Angreifer missbrauchen App-Schnittstellen und Metabase-Lücke

In Japan häufen sich Datenlecks, bei denen Angreifer persönliche Daten aus Web-Anwendungen und Apps abgreifen. Die Koordinierungsstelle JPCERT/CC hat dazu am 8. Oktober 2026 eine Warnung veröffentlicht und am 9. Oktober erweitert. Als Einfallstore nennt sie schlecht geschützte Programmierschnittstellen (APIs) hinter Smartphone-Apps, bekannte Sicherheitslücken und das Analysewerkzeug Metabase. Auch Deutschland taucht in einer begleitenden Auswertung auf.

Die Zahlen

JPCERT/CC selbst nennt keine Fallzahl und weder Täter noch betroffene Organisationen. Ihr Wissen sei „begrenzt und bruchstückhaft“. Die Warnung stützt sich unter anderem auf eine Analyse des japanischen Sicherheitsunternehmens Macnica vom 7. Oktober:

• 119 Vorfälle in Japan zwischen Januar und dem 6. Oktober 2026, bei denen persönliche Daten über Web-Systeme abflossen. Im ganzen Jahr 2025 waren es 84, im Jahr 2024 noch 62.
• 81 der 119 Fälle wurden ab Juli bekannt. Bei 65 davon reichten die Angaben nicht aus, um den Einstiegsweg zu erkennen.
• Außerhalb Japans zählt Macnica 99 ähnliche Fälle in 13 Ländern und Regionen, die meisten zwischen Juli und September. Südkorea führt mit 30 Fällen, gefolgt von Frankreich (11), Brasilien und den USA (je 10). Deutschland erscheint mit 4 Fällen, darunter der Missbrauch einer Buchungs-API.

Die Ziele sind breit gestreut: Onlineshops, Mitgliederportale, Geschäftsanwendungen und Kundendienste. Darunter waren auch eine Bibliotheksrecherche und das Reservierungssystem eines Ausflugszugs. Der größte bekannte Fall betrifft den Carsharing-Dienst Times Car von Park24. Dort gelangten Daten von rund 6,6 Millionen Konten nach außen, bei rund 1,6 Millionen davon auch Bilder von Ausweisdokumenten wie Führerscheinen. Kreditkartendaten waren laut Park24 nicht betroffen. Bei der Restaurantkette Yakiniku King sollen nach einem Bericht von INTERNET Watch knapp 10,8 Millionen Datensätze aus dem Mitgliedersystem der App abgeflossen sein.

Wie die Angreifer vorgehen

JPCERT/CC beschreibt inzwischen vier Muster:

1. Breites Scannen nach Lücken: Statt einer bestimmten Schwachstelle suchen die Angreifer bei jedem Ziel nach irgendeinem bekannten Fehler oder nach offen liegenden Konfigurations- und Backupdateien.
2. Missbrauch von App-Schnittstellen: Die Angreifer zerlegen öffentlich verfügbare Smartphone-Apps, um API-Adressen und darin eingebaute Schlüssel zu finden. Dann rufen sie auch interne Funktionen auf, die die App gar nicht anbietet, etwa um Benutzerrechte zu ändern oder Konten anzulegen. Teils nutzen sie API-Schlüssel, die bei anderen Einbrüchen erbeutet wurden.
3. Metabase-Lücke CVE-2026-72898 (siehe unten)
4. Neu seit 9. Oktober: Webshells, die als WAR- oder JSP-Dateien auf Java-Anwendungsservern abgelegt werden.

Laut Macnica nutzen die Angreifer vor allem einfache Fehler aus: APIs, die mehr Daten liefern als nötig, zu weit gefasste Rechte, Mitgliederfunktionen ohne Anmeldung, Logikfehler und schwache Passwörter für Verwaltungsoberflächen. Ob dabei KI hilft, ist nicht belegt. Der Macnica-Autor hält es aber für schwer vorstellbar, so viele Seiten von Hand zu prüfen. Als Zweck vermutet Macnica Material für Phishing und Betrug mit falschen Polizisten.

Metabase: Diese Versionen sollten laufen

Metabase ist ein quelloffenes Werkzeug für Auswertungen, das direkt an Unternehmensdatenbanken angebunden wird. Die Lücke CVE-2026-72898 ist eine SQL-Injection ohne Anmeldung mit der Höchstbewertung CVSS 10.0. Sie verschafft Administratorrechte in Metabase und damit Zugriff auf die gespeicherten Zugangsdaten der angebundenen Datenbanken. Metabase meldete am 6. August, dass sie als Zero-Day gegen den eigenen Clouddienst ausgenutzt wurde, die US-Behörde CISA führt sie seit dem 11. August als aktiv ausgenutzt.

Wichtig für Admins: Metabase hat nach dem ersten Fix weitere kritische Probleme gefunden und am 11. und 12. August nachgelegt. Der erste Fix reicht deshalb nicht.

Die Tabelle gilt für die Open-Source-Ausgabe. Versionen vor 58 sind von CVE-2026-72898 nicht betroffen. Wer nicht sofort aktualisieren kann, sollte den Endpunkt /api/session/reset_password sperren. Ein Hinweis auf einen Einbruch ist laut Metabase eine POST-Anfrage an diesen Endpunkt mit Antwort 400, auf die eine GET-Anfrage an /api/user/current mit Antwort 200 folgt.

War der Endpunkt aus dem Internet erreichbar, empfiehlt Metabase nach dem Update: alle Sitzungen beenden, unbekannte API-Schlüssel löschen, Administratorkonten prüfen, die Zugangsdaten aller angebundenen Datenbanken ändern und die Protokolle von Datenbank und Metabase auf ungewöhnliche Abfragen durchsehen.

Was Betreiber von Apps und Webdiensten tun sollten

JPCERT/CC und Macnica empfehlen unter anderem:

• Zugriffskontrolle auf jedem API-Endpunkt, auch auf solchen, die die App nicht nutzt
• Anfragen pro Zeiteinheit begrenzen, besonders bei Anmeldung, Passwort-Reset, SMS-Versand und Suche
• API-Tokens nur mit den nötigen Rechten, mit Ablaufdatum und schnell widerrufbar
• keine geheimen API-Schlüssel oder Datenbankzugänge in Apps oder Browser-Code einbauen, denn Verschleiern schützt sie nicht
• Verwaltungsfunktionen in Sicherheitstests einbeziehen und, wo möglich, nicht aus dem Internet erreichbar machen
• Protokolle rund einen Monat zurück prüfen: viele Anfragen von einer IP, plötzlich mehr Fehlerantworten (403, 404, 503), Aufrufe nicht existierender Funktionen
• Daten löschen, die nicht mehr gebraucht werden

Als Leitfaden verweist JPCERT/CC auf die OWASP API Security Top 10. Die Liste der IP-Adressen aus der Warnung ist inzwischen deutlich gewachsen. Macnica weist darauf hin, dass manche davon VPN-Ausgänge sind, die auch normale Nutzer verwenden. Ein Treffer im Log ist deshalb noch kein Beweis.

Einordnung

Die Welle zeigt ein Grundproblem vieler Apps: Die Oberfläche zeigt nur, was der Nutzer sehen soll, die Schnittstelle dahinter liefert aber oft deutlich mehr. Wer eine App oder einen Webdienst betreibt, sollte seine APIs so behandeln, als würde sie jeder direkt aufrufen, denn genau das passiert. Wie schnell Daten aus solchen Diensten abfließen können, zeigte zuletzt auch das Datenleck bei Gyazo.

Quellen: JPCERT/CC, Macnica, Park24, Metabase (6.8.), Metabase (12.8.), NVD, The Hacker News.