Cichy atak przez powszechnie wykorzystywaną bibliotekę
W świecie programistów JavaScript trudno o bibliotekę tak powszechnie obecną jak „is” – niewielką paczkę do sprawdzania typów, pobieraną tygodniowo ponad 2,8 miliona razy. To właśnie ona – dzięki swojej niskopoziomowej naturze – trafia jako zależność do tysięcy innych bibliotek, frameworków i narzędzi deweloperskich. Dlatego informacja, że w dniach 18–19 lipca 2025 r. do repozytorium trafiły zainfekowane wersje pakietu, natychmiast wzbudziła alarm. W oficjalnym komunikacie opiekuna projektu, Johna Harbanda, potwierdzono, że wersje oznaczone numerami od 3.3.1 do 5.0.0 zostały opublikowane nie przez niego, lecz przez osobę trzecią, która przejęła jego konto. Złośliwe wersje pozostały dostępne przez około sześć godzin – czas wystarczający, by trafić do środowisk wielu użytkowników. Zgodnie z analizą ekspertów ds. bezpieczeństwa, zainfekowane wydania zawierały backdoora – moduł pozwalający atakującym na zdalne wykonanie dowolnego kodu na maszynie ofiary. Atakujący uzyskiwał dostęp do zmiennych środowiskowych, informacji systemowych, a dzięki wykorzystaniu kanału WebSocket – także interaktywną powłokę do dalszego działania.
Skala ataku większa niż przypuszczano
W toku dalszych analiz ujawniono, że incydent nie dotyczył wyłącznie „is”. Z wykorzystaniem tego samego wektora ataku – fałszywej strony przypominającej portal NPM (domena npnjs[.]com) – przejęto konta również innych autorów, a następnie opublikowano zainfekowane wersje popularnych pakietów, takich jak eslint-config-prettier, eslint-plugin-prettier, syncpack czy got-fetch. W wielu przypadkach złośliwy kod miał charakter modularny – uruchamiał się jedynie w określonych środowiskach, ukrywał swoją obecność, unikał wykrycia przez narzędzia bezpieczeństwa i komunikował się z serwerami C2 (Command and Control). Część bibliotek zawierała także „Scavangera” – prostego, ale skutecznego złodzieja danych z przeglądarek. W odróżnieniu od wcześniejszych incydentów z udziałem złośliwego oprogramowania w ekosystemie NPM, tym razem atak był ukierunkowany i dobrze zaplanowany – obejmował przejęcie uwierzytelnienia opiekunów, celowe opublikowanie spreparowanych wersji i działania mające utrudnić wykrycie kompromitacji.
Jak zabezpieczyć projekty i ograniczyć skutki?
Z uwagi na powszechność wykorzystania zaatakowanych pakietów, środowisko open source zareagowało szybko. W ciągu kilku godzin od wykrycia incydentu zainfekowane wersje zostały wycofane, a NPM i GitHub podjęły działania mające na celu zabezpieczenie kont i wymuszenie resetu tokenów dostępowych.
Dla deweloperów najważniejsze jest teraz:
Zidentyfikowanie i usunięcie zainfekowanych wersji – zwłaszcza „is” w wersjach 3.3.1–5.0.0,
Zablokowanie aktualizacji do najnowszych wersji, jeśli nie są one zweryfikowane,
Wdrożenie plików lockfile (
package-lock.json,yarn.lock), które ograniczają ryzyko automatycznego pobrania złośliwego kodu,Ręczna rewizja zależności i ewentualne cofnięcie wersji do sprawdzonych wydań sprzed 18 lipca 2025 r.
Opiekunom pakietów zalecono także natychmiastową zmianę haseł, rotację tokenów NPM oraz włączenie uwierzytelniania dwuskładnikowego (2FA). Twórcy NPM zapowiadają wprowadzenie obowiązkowego 2FA dla bibliotek osiągających określony próg popularności.
W ocenie specjalistów, incydent ten może być jednym z największych tego typu ataków na ekosystem JavaScript – nie tylko ze względu na zasięg, ale też na profesjonalizm działań sprawców. Obawy budzi fakt, że infekcja mogła trafić do systemów produkcyjnych wielu firm, które automatycznie aktualizują zależności – co podkreśla potrzebę większej ostrożności w procesie CI/CD.
Na razie brak informacji o aktywnym wykorzystaniu zainfekowanych środowisk przez atakujących, ale incydent będzie prawdopodobnie analizowany jeszcze przez wiele tygodni.
