A japán szervezeteknél egymást követő személyesadat-szivárgások mögött álló támadók mobilalkalmazások API‑jait használták ki, és ismert szoftversebezhetőségeket céloztak meg – közölte a JPCERT Coordination Center (JPCERT/CC).

A tokiói központ, amely incidensjelentéseket fogad, ezekre a jelentésekre és más információkra alapozta 2026. október 8-i riasztását. A riasztás nem nevez meg sem támadókat, sem érintett szervezeteket.

A JPCERT/CC a riasztásban – amelynek szövegét japánról fordították – „korlátozottnak és töredékesnek” nevezi a rendelkezésére álló információkat. Hangsúlyozza, hogy a leírás nem jelenti azt, hogy minden incidensnél ugyanazt a módszert alkalmazták.

A fogyasztói alkalmazások mellett üzleti intelligencia (BI) eszközöket és olyan, dolgozóknak szánt menedzsmentrendszereket is támadtak, amelyek üzemeltetői nem számoltak azzal, hogy a nyilvánosság eléri őket. Több esetben kiszivárgott az ezekben tárolt adat.

A védők számára a riasztás nyolc forrás IP‑címet, öt User-Agent karakterláncot és egy API‑védelmi listát tartalmaz, köztük azzal, hogy minden végpontnál – akár nyilvános, akár nem – legyen megfelelő hozzáférés‑szabályozás.

Az egyetlen név szerint említett célpont a Metabase, egy BI eszköz, amelynek ismert sebezhetőségét támadók már kihasználták. A Metabase arra kérte a felhasználókat, hogy végezzenek verziófrissítést legalább a minimálisan biztonságos kiadásokra, amelyeket legutóbb augusztus 14-én frissítettek a listán. Ezek a kiadások újabbak, mint az adott sebezhetőség első javítása.

A szivárgások 2026 szeptemberében egymás után kerültek napvilágra. A JPCERT/CC szerint az ezek mögött álló támadások elkülönülnek a zsarolóvírusos és más szokásos incidensektől, nagy mennyiségű személyes adat kiszivárgásához vezetnek, és lehet, hogy egyre gyakoribbak.

A JPCERT/CC nem közölt darabszámot. Egy adat a japán Macnica cég Security Research Centerétől származik, egy október 7-én közzétett elemzésből, amelyre a riasztás is hivatkozik.

A Macnica 119 olyan incidenst számolt össze az idei évben október 6-ig, ahol Japánban működő szervezetek webes rendszerein keresztül loptak vagy szivárogtattak ki személyes adatokat. 2025-ben összesen 84, 2024-ben pedig 62 ilyen esetet talált, és az idei 119-ből 81 július óta történt.

A számlálás csak azokra az esetekre terjed ki, amelyeket a Macnica a mostani sorozathoz hasonlónak ítélt. Nem tartalmaz zsarolóvírusos ügyeket és azokat, amelyeket a Macnica más támadócsoportokhoz köt. A július óta nyilvánosságra került 81 esetből 65-ben túl kevés részlet derült ki ahhoz, hogy meg lehessen állapítani, hogyan jutottak be a támadók.

A célpontok köre az online boltoktól a tagsági szolgáltatásokon és üzleti rendszereken át az ügyfélszolgálati rendszerekig terjed. A legutóbbi esetek között szerepel egy könyvtár katalóguskeresője és egy turisztikai vonat helyfoglaló rendszere is.

Két eset jól mutatja a probléma nagyságát. A Park24 szeptember 28-án közölte, hogy egy illetéktelen harmadik fél mintegy 6,6 millió fiók adataihoz fért hozzá a Times Car autómegosztó szolgáltatás webes rendszerén keresztül. Egy nappal később azt is bejelentették, hogy személyazonosító okmányok, például jogosítványfotók szivárogtak ki körülbelül 1,6 millió fiókból.

A Yakiniku King étteremláncot üzemeltető Monogatari Corporation szerint 10 788 963 rekord szivárgott ki a Yakiniku King alkalmazás tagsági rendszeréből, írta az INTERNET Watch október 5-én. Mindkét cég azt közölte, hogy a kiváltó okot még vizsgálják.

A Macnica további 99 hasonló esetet talált 13 másik országban és régióban, főként július és szeptember között. Dél-Koreában 30-at, Franciaországban 11-et, Lengyelországban 8-at azonosítottak. Nem tudni, hogy kizárólag Japánt célozzák-e, és a Macnica arra is felhívta a figyelmet, hogy az egyes országokban eltérőek a közzétételi szabályok és gyakorlatok.

Hogyan jutnak be a támadók

A JPCERT/CC riasztása három mintát ír le. Az első az alkalmazás mögötti menedzsment API‑k jogosulatlan hívása. Egyes esetekben ezekkel a kérésekkel adatokat is átírtak.

A JPCERT/CC több jelentést kapott arról, hogy a támadók háromféleképpen csinálják ezt:

• Elemzik a nyilvánosan elérhető okostelefonos alkalmazást, és abból derítik ki az API‑végpontokat és kulcsokat.
• Olyan belső API‑kat támadnak, amelyeket az alkalmazás felületén keresztül nem lehet használni. A jelentések szerint többek között felhasználói jogosultságokat módosítanak, jogosulatlan fiókokat hoznak létre, összehasonlítják a szerver válaszait, ha egy fejlécet hozzáadnak vagy eltávolítanak, vagy hibás hitelesítési tokent küldenek, illetve blind NoSQL injection segítségével keresnek fiókadatokat.
• Olyan API‑kulcsokat használnak, amelyeket egy másik rendszer feltörésekor loptak el.

A Macnica bejegyzése ugyanezt a módszert írja le, részben incidenskezelési tapasztalatokra és logelemzésre támaszkodva. Egyes esetekben a támadók az okostelefonos alkalmazásból szerezték meg az API‑kulcsokat, majd úgy hívták az API‑t, mintha az alkalmazás normál használata történne.

A támadók minden egyes webhelyen és az ahhoz tartozó API‑kon olyan hibákat keresnek, amelyekkel adatokat tudnak megszerezni. Ilyenek például a szükségesnél több adatot visszaadó API‑k, a túlzott jogosultságokkal rendelkező API‑k, a névtelen felhasználók számára is elérhető tagsági funkciók, logikai hibák és a hibás munkamenet‑kezelés.

Néhány esetben gyenge adminfelület‑jelszavak elleni támadásokat és ismert hibák kihasználását is megerősítették.

A második minta egy lehetőség, amelyre a JPCERT/CC felhívja a figyelmet. Ahelyett, hogy minden célpontnál ugyanazt az egyetlen hibát használnák ki, a támadók minden rendszert külön átvizsgálhatnak ismert hibák egész sorára, és megpróbálhatják ezeket kihasználni. Emellett olyan támadásokkal is próbálkozhatnak, amelyek a gyenge rendszergazdai gyakorlatokra építenek, például konfigurációs és biztonsági mentéshez tartozó fájlok ellopásával.

A Metabase sebezhetőség és az ajánlott verziók

A harmadik minta a CVE-2026-72898 kihasználása. Ez egy SQL‑injection sebezhetőség a Metabase‑ben, egy nyílt forráskódú BI‑eszközben, amelyet a cégek az adatbázisaikhoz csatlakoztatnak.

A hibát zero‑dayként használták ki magával a Metabase felhőszolgáltatásával szemben – közölte a cég augusztus 6‑án. A sebezhetőség CVSS pontszáma 10,0. Az amerikai Cybersecurity and Infrastructure Security Agency (CISA) augusztus 11‑én felvette a Known Exploited Vulnerabilities katalógusába.

A támadónak nincs szüksége fiókra a kihasználásához. A hiba SQL‑injectiont tesz lehetővé a Metabase saját alkalmazás‑adatbázisába, ami adminisztrátori hozzáférést adhat. Innen a támadó ellophatja a csatlakoztatott adatbázisokhoz tartozó tárolt hitelesítő adatokat, és elolvashatja vagy exportálhatja az adataikat.

A JPCERT/CC augusztus 14‑én figyelmeztetett a hibára. Az új riasztás három forrás IP‑címet sorol fel, amelyeket augusztus elejétől szeptember elejéig használtak ki, valamint két User‑Agent példát. A riasztás nem részletezi, hogy ezekről a címekről mely szervezeteket érték el.

A támadások a javítás megjelenése után is folytatódtak. Az AhaSlides közölte, hogy egy harmadik fél kihasználta a hibát a Metabase‑rendszerében, és augusztus 12‑től szeptember 7‑ig hozzáfért ahhoz.

A Metabase augusztus 6‑i biztonsági frissítése javította a CVE-2026-72898 sebezhetőséget. A cég augusztus 11‑én újabb kritikus közleményt adott ki, amely olyan problémákat fed le, amelyeket saját állítása szerint maga talált. Ezzel egy időben megemelte az egyes verzióknál azt a legalacsonyabb kiadást, amelyet biztonságosnak tekint.

A táblázat mindkettőt mutatja a nyílt forráskódú buildekre. A Metabase az augusztus 6‑i javítások enterprise buildjeit 1.x‑szel, nem pedig 0.x‑szel számozza.

Verzió	CVE-2026-72898-at javító kiadás	A Metabase által biztonságosnak tekintett minimum kiadás
63	0.63.5	0.63.13
62	0.62.9	0.62.16
61	0.61.11	0.61.18
60	0.60.17	0.60.24
59	0.59.21	0.59.28
58	0.58.24	0.58.31

Az 58‑asnál régebbi verziókat nem érinti a CVE-2026-72898, a Metabase pedig már telepítette a javítócsomagot a felhőszolgáltatására.

Az üzemeltetők, akik egyelőre nem tudnak verziófrissítést végezni, ideiglenes megoldásként letilthatják az /api/session/reset_password végpontot. A Metabase ezt a kerülőmegoldást adja meg a CVE-2026-72898 esetére. Az augusztus 11‑i közlemény viszont egyértelműen verziófrissítést kér a felhasználóktól.

Nagy eséllyel kompromittálódott a szerver, ha a logokban egy 400‑as kóddal válaszolt POST /api/session/reset_password kérés után egy 200‑as kóddal válaszolt GET /api/user/current kérés látható – közölte a Metabase.

Ha a reset végpont az internetről is elérhető volt, a Metabase hat lépést sorol fel, amelyet a verziófrissítés után meg kell tenni:

• Vond vissza az összes aktív felhasználói munkamenetet.
• Nézd át az API‑kulcsokat, és törölj minden olyat, amit nem ismersz fel.
• Ellenőrizd az adminisztrátori fiókokat, nem történt‑e rajtuk váratlan módosítás.
• Cseréld le az összes csatlakoztatott adatbázis hitelesítő adatait.
• Nézd át az adattárház logjait jogosulatlan hozzáférés nyomai után kutatva.
• Ellenőrizd a Metabase aktivitási és lekérdezési előzményeit, nincs‑e bennük gyanús tevékenység.

Ami nem tisztázott

Sem a JPCERT/CC, sem a Macnica nem nevezi meg az aktivitás mögött álló személyt vagy csoportot, és nem állítják, hogy egyetlen csoport felelős mindenért.

A Macnica értékelése szerint a támadók bármilyen nyilvános webes rendszert megpróbálnak feltörni, amely személyes adatokat tárol, függetlenül attól, ki üzemelteti. Előfordulhat, hogy egy, már bevált módszert visznek át egyik célpontról a másikra, és bizonyos esetekben azonos forrás IP‑címeket használnak.

Eddig nem erősítették meg, hogy mesterséges intelligenciával felfedezett, széles körben használt szoftverekben lévő, korábban ismeretlen (zero‑day) hibákat használtak volna ki.

„Valójában olyan tevékenységet látunk, amely széles körben pásztázza és kihasználja az alapvetőbb hibákat, például a hozzáférési jogosultságok, a konfiguráció és a hitelesítés területén, illetve ismert sebezhetőségeket” – írta a Macnica bejegyzése a japán szöveg fordítása szerint.

Nincsenek olyan logok vagy nyomok, amelyek bizonyítanák a mesterséges intelligencia használatát. A bejegyzés szerzője mégis úgy véli, nehéz teljesen kizárni az AI használatát, mert ennyi webhelyet kézzel átnézni nem reális.

Egyik beszámoló sem részletezi, hogy az egyes nyilvános adatszivárgásoknál pontosan melyik módszert alkalmazták, mert egyik sem nevezi meg az érintett szervezeteket.

Indikátorok és ellenőrzések

A JPCERT/CC közzétette az alábbi forráscímeket és User-Agent példákat. Ezeket a megadott időszakokban visszaélésekhez használták, de mostanra akár teljesen normál forgalom is érkezhet róluk.

API‑visszaélés, 2026 szeptemberének környékén

• IP: 3.112.252[.]14
• IP: 54.95.112[.]6
• IP: 69.10.51[.]162
• IP: 172.86.91[.]7
• IP: 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‑kihasználás, 2026 augusztus elejétől szeptember elejéig

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

A Macnica szerint elsőként a 210.149.87[.]120 és a 69.10.51[.]162 címeket érdemes ellenőrizni. Elképzelhető, hogy ezek VPN kilépési címek, amelyeket teljesen hétköznapi felhasználók is megosztanak, ezért az innen érkező kérések önmagukban nem bizonyítják a támadást. Ha viszont nagy forgalom vagy sok hiba érkezik ezekről a címekről, érdemes részletesen átnézni a logokat.

Logelemzéshez a Macnica nagyjából egy hónapra visszamenőleg javasol vizsgálatot, és az alábbi jelekre érdemes figyelni:

• Erős API‑forgalom egyetlen IP‑címről
• Hirtelen megugró hibaválaszok, például 403, 404 és 503
• Nem létező fájlokra vagy API‑funkciókra irányuló kérések
• A szokásosnál jóval több kérés, még akkor is, ha a szerver 200‑as kóddal válaszol
• Olyan admin funkciók használata, amelyekhez a normál felhasználók nem férhetnek hozzá, vagy gyanús parancsvégrehajtás
• Admin funkciók elérése szokatlan IP‑címekről
• Megugró adatbázisterhelés vagy intenzív session‑használat a forgalomnövekedéssel egy időben
• Több hiba az adatbázis‑logokban
• Megnövekedett számú bejelentkezési kísérlet

API‑k esetén a JPCERT/CC hat védelmi intézkedést javasol, és az OWASP útmutatóira, például az OWASP API Security Top 10 dokumentumra hivatkozik részletekért:

• Korlátozni kell az időegység alatt engedélyezett kérések számát, hogy megállítsák az ismételt és tömeges hívásokat.
• Külön limitet kell beállítani azokra a funkciókra, amelyek erőforrás‑igényesek vagy könnyen visszaélhetők, például a bejelentkezésre, jelszó‑visszaállításra, SMS‑küldésre és keresésre.
• Minden API‑végpontra – a nem nyilvánosakra is – érvényesíteni kell a hozzáférés‑vezérlést, és csak engedélyezett felhasználóktól és HTTP‑metódusokkal szabad kéréseket elfogadni.
• Az API‑felhasználóknak és tokeneknek csak a feltétlenül szükséges jogosultságokat szabad megadni.
• API‑tokenekre lejárati időt kell beállítani, és kerülni kell a hosszú élettartamú tokeneket.
• Gyorsan vissza kell tudni vonni minden olyan tokent, amelyre már nincs szükség, vagy amely kiszivároghatott.

A Macnica két további ellenőrzést javasol. Titkos API‑kulcsokat és adatbázis‑hozzáférési adatokat nem szabad a kiadott alkalmazásba vagy a böngészőben futó kódba beépíteni, mert a kód tömörítése vagy obfuszkálása nem rejti el ezeket. A sebezhetőségi teszteknek ki kell térniük az admin funkciókra is, amelyeket gyakran kihagynak.

A JPCERT/CC általános javaslatai között szerepel a régió szerinti hozzáférés‑korlátozás, ha egy szolgáltatást csak egy adott régióban használnak, az interneten elérhető, felesleges admin funkciók letiltása, valamint a megőrzési időn túli adatok törlése.

A központ közölte, hogy az értesítést frissíti, ahogy többet tud meg az okokról és a módszerekről.

Az adatvédelmi felügyelet is riasztást adott ki

Japán személyesadat‑védelmi hatósága, a Personal Information Protection Commission október 7‑én saját riasztást adott ki a személyes adatokat kezelő vállalkozásoknak. Olyan esetekre hivatkozott, amikor széles körben használt szolgáltatásokat ért jogosulatlan hozzáférés, és nagy mennyiségű személyes adat szivárgott ki vagy szivároghatott ki. Emlékeztette a vállalkozásokat, hogy ellenőrizzék, valóban szükségük van‑e még a birtokukban lévő személyes adatokra.

A hatóság jogosulatlan hozzáférésből eredő szivárgásokról szóló útmutatója, amelyet ugyanezen a napon frissítettek, esettanulmányt is tartalmaz az API‑visszaélésről. Ebben a támadó bejelentkezik egy okostelefonos alkalmazásba vagy webes szolgáltatásba, átírja a kérés paramétereit, és így más felhasználók adataihoz jut hozzá.