Villámgyors támadás, profin kivitelezve
A támadók egy hosszú élettartamú npm-hozzáférési tokent loptak el az Axios egyik vezető fejlesztőjétől. Ez elég volt ahhoz, hogy publikáljanak két fertőzött verziót, amelyek a fejlesztői gépekre egy platformfüggetlen, távoli elérésű trójait (RAT-et) telepítettek Windows, macOS és Linux alatt is. A rosszindulatú csomagok három órán keresztül voltak elérhetők az npm-en, de már 89 másodperccel az első feltöltés után megkezdődtek a fertőzések, és a támadók legalább 135 rendszert kompromittáltak.
Egészen precízen és rejtetten jártak el: az Axios kódjába nem nyúltak bele; helyette mindkét fő kiadási ágban hozzáadtak egy új függőséget, a plain-crypto-js@4.2.1-et, amely önállóan semmit sem importál, csak azért létezik, hogy egy telepítés utáni szkriptet futtasson és telepítse a trójait. Tizennyolc órával a támadás előtt még egy „tiszta”, megtévesztő verziót is publikáltak ugyanezen a néven, hogy elkerüljék a csomagszkennerek figyelmét. Ezután következett a tényleges, támadó verzió két ágon, mindössze 39 percen belül.
Korszerű védekezés, de hiába
Az Axios fejlesztőcsapata minden egyes ajánlott biztonsági protokollt bevezetett: a kiadások GitHub Actionsből indultak, OIDC Trusted Publisher mechanizmussal, ami minden publikálást egy ellenőrzött CI/CD folyamathoz kötött. SLSA származást igazoló nyilatkozatokat is mellékeltek, így papíron a biztonság maximálisnak tűnt.
Ennek ellenére elég volt egyetlen megmaradt, régi típusú npm-token, amely még a modern OIDC-beállítások mellett is elsőbbséget élvezett. A támadó nem bontotta meg a biztonsági láncot, egyszerűen kikerülte azt: az npm parancssori eszköz csupán a legacy token meglétét figyelte, az új OIDC-t figyelmen kívül hagyta. Így minden modern védelmi intézkedés értelmét vesztette. Ilyen örökölt hitelesítési mechanizmusok nagyvállalati rendszerekben sem ritkák, és a történet erősen emlékeztet a SolarWinds-botrányra is.
Miért nem derült ki azonnal?
A valódi, nem fertőzött verziókról minden modern védelmi információ rendelkezésre állt: OIDC-eredetjelölés, hiteles kiadói rekord, konkrét commit-azonosító. Az álcázott, rosszindulatú verziókban ezek hiányoztak – bármilyen eszköz, amely ellenőrzi a csomag származását, azonnal kiszúrta volna. Csakhogy ez a védelem nem kötelező, a registry nem blokkolja a hiányos nyomvonalú csomagokat.
Nem egyedi eset: az ok ugyanaz
Az utóbbi hét hónapban ez már a harmadik jelentős npm-ellátási lánc kompromittálása, mind ugyanazzal az alappal: ellopott fejlesztői hitelesítő adatokkal. 2025 szeptemberében a Shai-Hulud-támadás, 2026 januárjában a Koi Security hat „zero-day” sérülékenységet mutatott ki több package managernél. Persze az npm a zúduló támadások után valóban új védelmeket vezetett be: az új klasszikus tokenek létrehozását megszüntették, bevezették a FIDO 2FA-t és az időzített/granuláris hozzáférést, de az alapszabály nem változott: a fejlesztői fiókok maradtak a lánc leggyengébb pontjai. A támadások azokat célozzák.
Hiába minden rétegzett védelem, amíg a fő fejlesztői hozzáférések, a hitelesítési adatok, tokenek ott vannak: ezek maradnak a fő rizikófaktorok. Mindegy, hány szabály van, ha egy figyelmetlenség miatt egy örökölt token él, minden borulhat.
Mik voltak a vakfoltok?
Az npm igazán fontos biztonsági frissítéseket vezetett be, mégsem tudta megelőzni a támadást:
- Az ellopott tokenek blokkolását kötelező FIDO 2FA-val és 7 napos érvényű tokenekkel próbálták elérni, de a rendszer automatikusan a régi tokeneket használta tovább.
- A csomagok származásának ellenőrzése is csak ajánlott volt, a registry nem szűrte a bizonyíték nélküli kiadásokat.
- A telepítés utáni szkriptek futtatása nagy malware-forrás, az npm továbbra sem blokkolja alapértelmezésben, szemben a pnpm-mel.
- A lockfile-ra épülő függőségkezelés ténylegesen csak akkor véd, ha a kompromittált csomag megjelenése előtt commitolják.
Mi a teendő most?
A Node.js-t használó cégeknek ezt az incidenst érdemes aktív veszélyként kezelni, legalább addig, amíg minden rendszerüket nem ellenőrizték. Az érintett időszak különösen az ázsiai fejlesztői munkaidőkkel esett egybe, bármelyik CI/CD pipeline magától is letölthette az érintett csomagot.
Az első lépés: derítsd fel, melyik build és downstream-felhasználó használta a fertőzött verziókat: axios@1.14.1, axios@0.30.4, vagy plain-crypto-js. Állítsd vissza az axios-t 1.14.0-ra vagy 0.30.3-ra.
Ha kompromittált gépet találsz, azonnal építsd újra ismert jó állapotból. Cserélj minden elérhető hitelesítőt, npm-tokeneket, AWS-kulcsokat, SSH-kulcsokat, CI/CD titkosakat.
Tiltólistára kell tenni a támadók parancsközpontját (távoli elérési címet). Ellenőrizd a következő fájlokat és mappákat: macOS-en /Library/Caches/com.apple.act.mond, Windowson %PROGRAMDATA%wt.exe, Linuxon /tmp/ld.py. Ha ilyet találsz, teljes újratelepítés kell.
A jövőre nézve: csak –ignore-scripts kapcsolóval induljon az npm-telepítés CI/CD-ben, minden csomagnál kötelező legyen a származás igazolása, és nézd át, nincs-e régi token az OIDC mellett.
A hiányzó láncszem: a fejlesztői hitelesítők
A legérdekesebb rész még csak ezután jön: bárhány védelmi réteg kerül a rendszerbe, az npm ma is a karbantartók fiókjait kezeli bizalmi központként. Ezek pedig mindig is a támadók célpontjai lesznek, függetlenül a hozzáadott biztonsági megoldásoktól.
Az MI már képes felderíteni a problémás csomagokat, auditálni a régi jogosultságokat, de a fejlesztői jelszavak továbbra is emberek kezében maradnak. Itt maximum csökkenthető a kockázat, de teljesen nem szüntethető meg.
Az egyetlen, valóban működő megoldás az lenne, ha a CLI-s kiadást teljesen letiltanák azoknál a projekteknél, ahol van OIDC Trusted Publishing, vagy kötelezővé tennék a több aláíróval történő kiadást. Ez azonban még csak terv az npm-nél, addig minden OIDC-vel futó projekt ugyanazzal a vakfolttal küzd, mint most az Axios. Összefoglalva: egyetlen, rég elfeledett token miatt hiúsult meg az egész közösség eredménye.
