JPCERT/CC bezeichnet den eigenen Kenntnisstand ausdrücklich als „begrenzt und bruchstückhaft" und betont, die Darstellung bedeute nicht, dass in jedem Vorfall dieselbe Methode zum Einsatz kam. Betroffen sind neben Verbraucher-Apps auch BI-Werkzeuge und interne Verwaltungssysteme für Beschäftigte, bei denen die Betreiber nicht damit rechneten, dass sie aus dem Internet erreichbar sind. In einigen Fällen flossen darin gespeicherte Daten ab.

Die Vorfälle traten um den September 2026 herum in rascher Folge auf. Nach Einschätzung von JPCERT/CC unterscheiden sich die dahinterstehenden Angriffe von Ransomware und anderen Routinevorfällen, führen zum Abfluss großer Mengen personenbezogener Daten und nehmen möglicherweise zu. Eine eigene Zählung legt das Zentrum nicht vor.

Zahlen aus der Analyse von Macnica

Eine Zählung stammt vom Security Research Center des japanischen Unternehmens Macnica, dessen am 7. Oktober veröffentlichte Analyse die Warnung zitiert. Macnica kommt für dieses Jahr bis zum 6. Oktober auf 119 öffentlich gewordene Vorfälle, bei denen personenbezogene Daten über Websysteme von Organisationen in Japan entwendet wurden oder abflossen. Für das gesamte Jahr 2025 zählte Macnica 84 Fälle, für 2024 62. 81 der 119 diesjährigen Fälle entfielen auf Juli oder später. Erfasst sind nur Vorfälle, die Macnica als der aktuellen Serie ähnlich einstuft; Ransomware und Fälle, die Macnica anderen Angreifergruppen zuordnet, bleiben außen vor. Von den 81 seit Juli bekanntgewordenen Fällen enthielten 65 zu wenig Details, um den Einstiegsweg zu bestimmen.

Die Ziele haben sich von Online-Shops auf Mitgliederdienste, Geschäftssysteme und Kundensupport ausgeweitet. Zu den jüngeren Fällen zählen die Katalogsuche einer Bibliothek und das Sitzplatzbuchungssystem eines Touristenzugs.

Zwei Fälle zeigen die Größenordnung: Park24 teilte am 28. September mit, ein Dritter habe aus dem Websystem des Carsharing-Dienstes Times Car Daten zu rund 6,6 Millionen Konten erlangt. Einen Tag später erklärte das Unternehmen, aus etwa 1,6 Millionen Konten seien Ausweisdokumente abgeflossen, darunter Bilder von Führerscheinen. Die Monogatari Corporation, Betreiberin der Restaurantkette Yakiniku King, gab an, aus dem Mitgliedersystem der Yakiniku-King-App seien 10.788.963 Datensätze abgeflossen; darüber berichtete INTERNET Watch am 5. Oktober. Beide Unternehmen erklärten zu diesem Zeitpunkt, die Ursache werde noch untersucht.

Macnica fand zudem 99 ähnliche Fälle in 13 weiteren Ländern und Regionen, überwiegend von Juli bis September, darunter 30 in Südkorea, 11 in Frankreich und 8 in Polen. Ob Japan das einzige Ziel ist, ist nicht bekannt; Meldepflichten und Veröffentlichungspraxis unterscheiden sich nach Land.

Drei Muster beim Einstieg

Das erste Muster sind unautorisierte Anfragen an die Verwaltungs-APIs hinter einer App. In einigen Fällen wurden damit Informationen überschrieben. JPCERT/CC liegen mehrere Meldungen zu drei Vorgehensweisen vor:

  • Analyse einer öffentlich verfügbaren Smartphone-App, um deren API-Endpunkte und Schlüssel zu finden.
  • Angriffe auf interne APIs, die über die App-Oberfläche nicht nutzbar sind. Gemeldet wurden unter anderem das Ändern von Nutzerrechten, das Anlegen unautorisierter Konten, der Vergleich der Serverantworten beim Hinzufügen oder Entfernen eines Headers oder beim Senden eines fehlerhaften Authentifizierungstokens sowie das Auslesen von Kontodaten per Blind-NoSQL-Injection.
  • Verwendung von API-Schlüsseln, die bei der Kompromittierung eines anderen Systems entwendet wurden.

Macnica beschreibt dieselbe Methode in einem Abschnitt, der auf Incident Response und Log-Analysen beruht. In manchen Fällen entnahmen Angreifer API-Schlüssel einer Smartphone-App und riefen die API so auf, dass es wie normale Nutzung aussah. Die Angreifer durchsuchen jede Website und deren APIs nach jeder Schwäche, die Datenzugriff erlaubt: APIs, die mehr Daten zurückgeben als nötig, APIs mit übermäßigen Rechten, für anonyme Nutzer erreichbare Mitgliederfunktionen, Logikfehler und Mängel im Sitzungsmanagement. Auch Angriffe auf schwache Passwörter von Administrationsoberflächen und die Ausnutzung bekannter Lücken wurden in einzelnen Fällen bestätigt.

Das zweite Muster ist eine von JPCERT/CC aufgeworfene Möglichkeit: Statt sich auf eine einzige, allen Zielen gemeinsame Lücke zu stützen, könnten die Angreifer jedes Ziel auf eine Reihe bekannter Schwachstellen prüfen und diese auszunutzen versuchen. Ebenso könnten sie Angriffe erproben, die auf mangelhafte Systempflege zielen, etwa das Entwenden von Konfigurations- und Backup-Dateien.

Die Metabase-Lücke CVE-2026-72898

Das dritte Muster ist die Ausnutzung von CVE-2026-72898, einer SQL-Injection-Schwachstelle in Metabase, einem quelloffenen BI-Werkzeug, das Unternehmen mit ihren Datenbanken verbinden. Metabase ist das einzige in der Warnung namentlich genannte Zielprodukt. Nach Angaben des Unternehmens vom 6. August wurde die Lücke als Zero-Day gegen den eigenen Cloud-Dienst von Metabase ausgenutzt. Der CVSS-Wert beträgt 10.0. Die US-Behörde CISA nahm die Schwachstelle am 11. August in ihren Katalog bekannter ausgenutzter Schwachstellen auf.

Zur Ausnutzung ist kein Konto nötig. Die Lücke erlaubt SQL-Injection in Metabases eigene Anwendungsdatenbank, was Administratorzugriff verschaffen kann. Von dort ließen sich die gespeicherten Zugangsdaten angebundener Datenbanken entwenden und deren Daten lesen oder exportieren.

JPCERT/CC hatte am 14. August vor der Lücke gewarnt. Die neue Warnung ergänzt drei Quell-IP-Adressen, die von Anfang August bis Anfang September missbraucht wurden, sowie zwei User-Agent-Beispiele. Welche Organisationen von Anfragen aus diesen Adressen betroffen waren, nennt die Warnung nicht.

Angriffe setzten sich auch nach Verfügbarkeit des Fixes fort: AhaSlides erklärte, ein Dritter habe die Lücke in seiner Metabase-Installation ausgenutzt und vom 12. August bis zum 7. September Zugriff gehabt.

Metabases Sicherheitsupdate vom 6. August behob CVE-2026-72898. Am 11. August veröffentlichte das Unternehmen eine weitere kritische Sicherheitsmitteilung zu Problemen, die es nach eigenen Angaben selbst gefunden hat, und hob daraufhin die jeweils niedrigste als sicher bezeichnete Version an. Die zuletzt am 14. August aktualisierte Liste der Mindestversionen liegt damit über dem ersten Fix für die Lücke. Für die Enterprise-Builds nummeriert Metabase die Fixes vom 6. August mit 1.x statt 0.x. Versionen unterhalb von 58 sind von CVE-2026-72898 nicht betroffen; den eigenen Cloud-Dienst hat Metabase bereits gepatcht.

Wer noch nicht aktualisieren kann, kann als vorübergehende Maßnahme den Endpunkt /api/session/reset_password sperren – diesen Behelf nennt Metabase für CVE-2026-72898. Die Mitteilung vom 11. August fordert zum Upgrade auf. Ein Server ist laut Metabase wahrscheinlich kompromittiert, wenn die Logs eine Anfrage POST /api/session/reset_password mit Statuscode 400 zeigen, gefolgt von GET /api/user/current mit Statuscode 200.

War der Reset-Endpunkt aus dem Internet erreichbar, nennt Metabase sechs Schritte nach dem Upgrade:

  • Alle aktiven Nutzersitzungen widerrufen.
  • API-Schlüssel prüfen und unbekannte löschen.
  • Administratorkonten auf unerwartete Änderungen prüfen.
  • Zugangsdaten jeder angebundenen Datenbank wechseln.
  • Logs des Data Warehouse auf Anzeichen unbefugter Zugriffe prüfen.
  • Aktivitäts- und Abfrageverlauf von Metabase auf Auffälligkeiten prüfen.

Was nicht belegt ist

Weder JPCERT/CC noch Macnica benennen eine Person oder Gruppe hinter den Aktivitäten oder erklären eine einzelne Gruppe für verantwortlich. Nach Einschätzung von Macnica versuchen die Angreifer es bei jedem öffentlich erreichbaren Websystem mit personenbezogenen Daten, unabhängig vom Betreiber; sie setzen eine bei einem Ziel erfolgreiche Methode möglicherweise bei weiteren ein und nutzen teils dieselben Quell-IP-Adressen.

Der Einsatz von per KI entdeckten Zero-Day-Lücken in verbreiteter Software ist bislang nicht bestätigt. „Was tatsächlich geschieht, ist eine Aktivität, die breit nach grundlegenderen Mängeln in Bereichen wie Zugriffsrechten, Konfiguration und Authentifizierung sowie nach bekannten Schwachstellen sucht und diese ausnutzt", heißt es im Beitrag von Macnica. Logs oder Spuren, die einen KI-Einsatz belegen, gibt es nicht; der Autor hält einen solchen Einsatz dennoch für schwer auszuschließen, da eine manuelle Prüfung so vieler Websites nicht realistisch sei. Welche öffentlich bekannte Datenpanne auf welche Methode zurückgeht, sagt keine der beiden Darstellungen, da keine betroffene Organisation genannt wird.

Indikatoren und Prüfungen

JPCERT/CC veröffentlichte acht Quell-IP-Adressen und fünf User-Agent-Zeichenketten. Die Adressen wurden in den angegebenen Zeiträumen missbraucht und können inzwischen normal genutzt werden.

API-Missbrauch, um September 2026:

  • 3.112.252[.]14
  • 54.95.112[.]6
  • 69.10.51[.]162
  • 172.86.91[.]7
  • 210.149.87[.]120
  • User-Agent: curl/7.88.1
  • User-Agent: python-requests/2.34.2
  • User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36

Metabase-Ausnutzung, Anfang August bis Anfang September 2026:

  • 213.163.202[.]171
  • 221.216.140[.]49
  • 221.216.140[.]129
  • User-Agent: python-requests/2.33.1
  • User-Agent: Metabase-GHSA-vwf4/2.0

Macnica nennt 210.149.87[.]120 und 69.10.51[.]162 als zuerst zu prüfende Adressen. Sie können VPN-Ausgangsadressen enthalten, die auch normale Nutzer teilen; eine Anfrage von dort ist daher kein Beweis für einen Angriff. Starker Verkehr oder viele Fehler aus diesen Adressen erfordern eine genaue Log-Prüfung.

Für Logs empfiehlt Macnica, rund einen Monat zurückzugehen und auf Folgendes zu achten:

  • starker API-Verkehr von einer einzelnen IP-Adresse
  • plötzlicher Anstieg von Fehlerantworten wie 403, 404 und 503
  • Anfragen nach nicht existierenden Dateien oder API-Funktionen
  • deutlich mehr Anfragen als üblich, auch bei Antwort 200
  • Nutzung von Adminfunktionen, die gewöhnlichen Nutzern nicht erlaubt sind, oder verdächtige Befehlsausführung
  • Zugriffe auf Adminfunktionen von ungewöhnlichen IP-Adressen
  • hohe Datenbanklast oder starke Sitzungsnutzung zeitgleich mit steigendem Verkehr
  • mehr Fehler in den Datenbank-Logs
  • mehr Anmeldeversuche

Für APIs empfiehlt JPCERT/CC sechs Maßnahmen und verweist für Details auf OWASP-Material wie die OWASP API Security Top 10:

  • Zahl der Anfragen pro Zeiteinheit begrenzen, um wiederholte und massenhafte Aufrufe zu unterbinden.
  • Gesonderte Raten- oder Nutzungsgrenzen für aufwendige oder leicht missbrauchbare Funktionen wie Login, Passwort-Reset, SMS-Versand und Suche.
  • Zugriffskontrolle auf jedem API-Endpunkt durchsetzen, auch auf nicht öffentlichen, und nur erlaubte Nutzer und HTTP-Methoden akzeptieren.
  • API-Nutzern und Tokens nur die nötigen Rechte geben.
  • API-Tokens mit Ablaufdatum versehen und langlebige Tokens vermeiden.
  • Nicht mehr benötigte oder möglicherweise abgeflossene Tokens schnell widerrufen können.

Macnica ergänzt zwei Prüfpunkte: Geheime API-Schlüssel und Datenbank-Zugangsdaten gehören nicht in ausgelieferte Apps oder Browser-Code, da Minifizierung oder Obfuskation sie nicht verbirgt. Schwachstellentests sollten Adminfunktionen einschließen, die häufig ausgespart bleiben. Die allgemeinen Empfehlungen von JPCERT/CC umfassen zudem, den Zugriff regional zu beschränken, wenn ein Dienst nur in einer Region genutzt wird, unnötige Adminfunktionen im Internet abzuschalten und Daten nach Ablauf der Aufbewahrungsfrist zu löschen. Das Zentrum kündigte an, die Warnung zu aktualisieren, sobald mehr über Ursachen und Methoden bekannt ist.

Datenschutzbehörde warnt ebenfalls

Japans Personal Information Protection Commission veröffentlichte am 7. Oktober eine eigene Warnung an Unternehmen, die personenbezogene Daten verarbeiten. Sie verwies auf Fälle, in denen weit verbreitete Dienste von unbefugten Zugriffen betroffen waren und große Mengen personenbezogener Daten abflossen oder abgeflossen sein könnten, und erinnerte daran zu prüfen, ob die gespeicherten Daten noch benötigt werden. Die am selben Tag überarbeitete Handreichung der Kommission zu Datenabflüssen durch unbefugten Zugriff enthält eine Fallstudie zum API-Missbrauch: Darin meldet sich ein Angreifer bei einer Smartphone-App oder einem Webdienst an, verändert Anfrageparameter und gelangt so an Daten anderer Nutzer.