Japońskie centrum JPCERT/CC opisało cztery drogi, którymi napastnicy wynosili dane z japońskich firm, a każda działa też w polskiej firmie z aplikacją mobilną albo narzędziem do raportów. Ostrzeżenie z 8 i 9 października 2026 roku wymienia znane luki, wewnętrzne API wyciągnięte z aplikacji na telefon, lukę w Metabase i webshell na serwerze aplikacji. Według telewizji NHK od końca września ucierpiało co najmniej 18 organizacji. Wśród nich są Tokyo Metro, dziennik Nikkei i Japońska Agencja Energii Atomowej. Minister cyfryzacji Masaaki Taira mówi według “Financial Times” o “cybersecurity emergency”, czyli nadzwyczajnej sytuacji w cyberbezpieczeństwie. Kto stoi za atakami, nie wiadomo.
Wyciek danych w Japonii: Tokyo Metro, Nikkei i agencja atomowa
Pierwsze komunikaty pojawiły się pod koniec września. Tokyo Metro ogłosiło 27 września, że osoba trzecia dostała się do serwera programu lojalnościowego. Według relacji serwisu Internet Watch mogło wyciec około 59 tys. adresów e-mail, na które firma wstrzymała wysyłkę. Innych danych klientów na tym serwerze nie było.
Japońska Agencja Energii Atomowej (JAEA) poinformowała 1 października o włamaniu z 25 września. Ktoś pobrał wtedy 2 419 plików z jej strony wsparcia badań działającej w chmurze. W 367 plikach były dane 175 osób. Chodzi o 200 zdjęć dokumentów tożsamości, 146 wyników badań lekarskich osób pracujących z promieniowaniem i 21 zaświadczeń. Wśród dokumentów były prawa jazdy, paszporty i karty pobytu.
Nikkei ogłosił 4 października, że ktoś przejął konto Microsoft 365 jednego z pracowników. 30 września wysłano z niego około 9 tys. fałszywych maili do osób w redakcji i jej rozmówców. Osobno gazeta zgłosiła włamanie na konto Google Workspace jednego z pracowników, z którego mogły wyciec dane 1 646 osób.
Według heise online, który powołuje się na NHK, największy wyciek dotknął sieć restauracji Yakiniku King. Chodzi o dane 10,8 mln klientów. NHK naliczyło co najmniej 18 podobnych przypadków, a “Financial Times” pisze o co najmniej 20 firmach. Na zdjęciu wyróżniającym: pociąg Tokyo Metro przy stacji Ochanomizu w Tokio. Fot. Kabelleger / David Gubler, Wikimedia Commons, licencja CC BY-SA 4.0.
Czy Japonia ogłosiła stan wyjątkowy w cyberprzestrzeni
Nie w sensie prawnym. Słowa o “cybersecurity emergency” to wypowiedź ministra cyfryzacji dla “Financial Times”. Według heise minister Taira zwołał 9 października kryzysowe spotkanie z urzędnikami krajowego biura ds. cyberbezpieczeństwa. Minister odpowiedzialny za cyberbezpieczeństwo Toshiharu Furukawa nazwał sytuację “extremely critical”. W pierwszym kroku ostrzeżenia mają trafić do ministerstw, a przez nie do samorządów i firm.
Najbardziej konkretna reakcja dotyczy banków. Według heise japoński nadzór bankowy zaleca bankom przyjmowanie przy otwieraniu konta tylko dokumentów z chipem NFC. Powód: napastnicy mogli wynieść dużo zdjęć dokumentów. Zdjęcie prawa jazdy da się wykorzystać ponownie, a dane w chipie trzeba odczytać z fizycznego dokumentu. To lekcja także dla polskich firm, które przy zakładaniu konta proszą klienta o skan dowodu. Każdy taki skan może posłużyć do kradzieży tożsamości, jak przy wycieku 153 mln skanów praw jazdy w USA.
Pierwsza Misja AI · Kodożercy
AI zmienia rynek pracy. Zacznij rozumieć, o co chodzi.
Kurs Pierwsza Misja AI to najkrótszy kurs, po którym naprawdę rozumiesz AI, a na koniec możesz to pokazać certyfikatem. Fabuła w konwencji science fiction i gamifikacja sprawiają, że nie nudzisz się ani minuty.
Dołącz do kursantów →
Cztery drogi ataku według JPCERT
Ostrzeżenie JPCERT-AT-2026-0030 opisuje cztery przypadki zgłoszone do centrum. JPCERT zastrzega, że jego informacje są “ograniczone i fragmentaryczne”, a ataki nie korzystają z jednej wspólnej luki. Nie wszystkie wycieki przeszły tą samą drogą. Ostrzeżenie obejmuje ataki nastawione na wynoszenie dużych ilości danych osobowych, bez zwykłych ataków ransomware. JPCERT podkreśla też, że ofiarami bywają narzędzia BI do raportów i systemy dla pracowników. Tych programów nikt nie projektował pod dostęp z całego internetu.
Tabelę ułożyliśmy na podstawie ostrzeżenia JPCERT i jego zaleceń, które przetłumaczyliśmy z japońskiego.
| Droga ataku | Co robi napastnik | Co sprawdzić u siebie |
|---|---|---|
| A. Znane luki i błędy konfiguracji | Skanuje każdy cel pod kątem różnych znanych luk, kradnie pliki konfiguracyjne i kopie zapasowe zostawione na serwerze | Aktualizacje wszystkiego, co widać z internetu; czy pliki konfiguracyjne i kopie zapasowe nie leżą w katalogu publicznym |
| B. Wewnętrzne API aplikacji mobilnej | Rozbiera publiczną aplikację na telefon, wyciąga adresy API i klucze, wywołuje funkcje niedostępne z ekranu (zmiana uprawnień, zakładanie kont), szuka kont ślepym wstrzyknięciem NoSQL, używa kluczy API skradzionych gdzie indziej | Kontrola uprawnień na każdym punkcie API, także “ukrytym”; limity zapytań, osobne dla logowania, resetu hasła, SMS i wyszukiwania; krótka ważność tokenów i szybkie unieważnianie |
| C. Luka w Metabase CVE-2026-72898 | Wstrzykuje zapytanie SQL przez API resetowania hasła bez logowania i przejmuje konto administratora | Wersja Metabase, blokada /api/session/reset_password z internetu, logi pod kątem śladów opisanych niżej |
| D. Webshell na serwerze aplikacji | Wgrywa plik WAR z ukrytym skryptem JSP, który wykonuje polecenia przekazane w adresie | Czy serwer aplikacji jest osiągalny z publicznego serwera WWW; nowe pliki WAR; ograniczenie ruchu po przejęciu serwera WWW |
Do tego JPCERT zaleca ograniczyć dostęp do krajów, z których korzystają klienci, i zdjąć z internetu zbędne panele administracyjne. Radzi też kasować dane po okresie przechowywania i z wyprzedzeniem przygotować klientów na wyciek, na przykład zachęcając do logowania dwuskładnikowego. W ostrzeżeniu są też podejrzane adresy IP obserwowane podczas ataków i przykładowe nagłówki User-Agent, w tym curl/7.88.1 i python-requests. Warto je sprawdzić we własnych logach.
Luka w Metabase CVE-2026-72898: kogo dotyczy
Luka pozwala bez logowania wysłać spreparowane zapytanie do Metabase i przejąć uprawnienia administratora. Metabase ogłosił ją 6 sierpnia 2026 roku czasu japońskiego, a według producenta była wykorzystywana, zanim powstała poprawka. Amerykańska baza NVD daje jej ocenę 10 na 10. CISA dopisała ją 11 sierpnia do katalogu luk wykorzystywanych w atakach.
Podatne są wersje od 58 do 63 sprzed wydań x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 i x.63.5. Wersje sprzed 58 luki nie mają, a Metabase Cloud producent załatał sam. Według ostrzeżenia JPCERT o Metabase ślad ataku to dwa wywołania z rzędu w logach: POST /api/session/reset_password z kodem 400, a zaraz potem GET /api/user/current z kodem 200. Jeśli takie wywołanie widać w logach, sama aktualizacja nie wystarczy. Trzeba przejrzeć sesje, klucze API i konta administratorów oraz zmienić hasła do baz podłączonych do Metabase.
Pisaliśmy o tej luce w sierpniu, gdy CISA dopisała Metabase do katalogu, i wcześniej przy wycieku danych klientów Frameworka przez Metabase. Według JPCERT luka była wykorzystywana w Japonii od początku sierpnia do początku września, także po publikacji poprawki.
Co polska firma powinna sprawdzić po atakach w Japonii
Nic nie wskazuje, że ta sama grupa celuje w polskie firmy, ale metody opisane przez JPCERT zadziałają wszędzie tam, gdzie są te same słabe punkty.
- Aplikacja mobilna. Wszystko, co aplikacja wysyła do serwera, napastnik zobaczy po jej rozebraniu. Punkt API “używany tylko przez aplikację” jest dostępny dla każdego. Serwer musi sam sprawdzać, czy dany użytkownik może zmienić uprawnienia albo pobrać cudze dane. Podobny błąd opisywaliśmy przy wycieku w Lovable.
- Narzędzie BI. Metabase, panel raportów albo system dla pracowników nie powinien być widoczny z internetu bez VPN albo innej warstwy logowania. Jeśli musi, aktualizujcie je w dniu wydania poprawki.
- Skany dowodów klientów. Jeśli firma ich nie potrzebuje, nie powinna ich trzymać. Jeśli potrzebuje, powinna je kasować po okresie wymaganym przepisami, zgodnie z zaleceniem JPCERT.
- Plan na wyciek. Jeśli naruszenie może powodować ryzyko dla praw lub wolności osób, firma zgłasza je do UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia (art. 33 RODO). Lepiej wiedzieć wcześniej, kto w firmie to robi.
Co grozi firmie, z której wyciekły dane klientów, i jak wyglądają roszczenia, opisaliśmy w tekście o odszkodowaniu za wyciek danych.
FAQ
Czy w atakach w Japonii użyto sztucznej inteligencji?
Tego nie ustalono. Ostrzeżenie JPCERT o AI nie wspomina, a heise pisze, że sprawcy są nieznani. Nie wiadomo też, czy za wszystkimi przypadkami stoi jedna grupa. JPCERT opisuje cztery różne metody i zaznacza, że nie każdy wyciek przebiegł tak samo.
{ dla firm }Co możemy zrobić dla Twojej firmy?
Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.
Podsumowanie
Od końca września 2026 roku w Japonii wyciekły dane z co najmniej 18 firm i instytucji według NHK. “Financial Times” pisze o co najmniej 20. Wśród nich są Tokyo Metro, Nikkei, JAEA i Yakiniku King. JPCERT/CC opisał 8 i 9 października cztery drogi ataku. To znane luki i błędy konfiguracji, wewnętrzne API aplikacji mobilnych, lukę w Metabase CVE-2026-72898 oraz webshell na serwerze aplikacji. Minister cyfryzacji mówi o nadzwyczajnej sytuacji, ale stanu wyjątkowego w sensie prawnym nie ogłoszono. Nadzór bankowy zaleca bankom dokumenty z chipem zamiast zdjęć. Sprawcy pozostają nieznani. Polska firma z aplikacją mobilną albo narzędziem BI powinna dziś sprawdzić kontrolę uprawnień w API, wersję Metabase i logi. Warto też zapytać, czy w ogóle musi trzymać skany dowodów klientów.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
