Rano 31 marca 2026 roku setki programistów odkryło, że biblioteka axios, z której korzystają na co dzień, przez trzy godziny w nocy zawierała złośliwy kod kradnący dane z ich maszyn. Ktoś przejął konto maintainera projektu, opublikował zainfekowaną wersję i zanim npm zdążył ją usunąć, automatyczne buildy i nocne aktualizacje pobrały ją na miliony serwerów deweloperskich. Atak na axios to jeden z najgroźniejszych incydentów w historii ekosystemu npm. To też wyjątkowo dobry powód, żeby sprawdzić co robi Twój pipeline CI/CD o trzeciej w nocy.
Co się stało? Atak na axios krok po kroku
Atak był precyzyjnie zaplanowany, nie przypadkowy. O godzinie 23:59:12 UTC 30 marca 2026 na npm pojawiły się dwie nowe wersje biblioteki: axios@1.14.1 oraz axios@0.30.4. Obie zawierały dodatkową zależność, której nie ma w legalnym kodzie źródłowym projektu: plain-crypto-js w wersji 4.2.1. Ten pakiet był przygotowany 18 godzin wcześniej, co wskazuje na zaplanowany atak, a nie improwizację.
Atakujący przejął konto jednego z głównych maintainerów axios na npm. Po uzyskaniu dostępu zmienił adres e-mail konta na anonimowy adres ProtonMail i opublikował paczki bezpośrednio przez npm CLI, pomijając tym samym firmowy pipeline GitHub Actions, który normalnie pilnuje procesu wydawania nowych wersji.
Axios to jedna z najpopularniejszych bibliotek JavaScript do wysyłania zapytań HTTP, z ponad 300 milionami pobrań tygodniowo. W oknie trwającym około trzech godzin zainfekowane wersje były dostępne jako latest i mogły trafić do wszystkich, którzy w tym czasie wykonali npm install, npm update lub odpalili automatyczny build CI/CD.
Jak działał złośliwy kod? Anatomia ataku RAT
Złośliwy kod działał jako RAT (Remote Access Trojan) z funkcją automatycznego samozniszczenia.
Skrypt postinstall uruchamiał się natychmiast po zainstalowaniu pakietu, bez interakcji użytkownika. Działał na wszystkich trzech głównych systemach operacyjnych: macOS, Windows i Linux. Po połączeniu z serwerem C2 (command and control) pobierał payload dopasowany do systemu operacyjnego i przystępował do zbierania danych. Cel był konkretny: klucze SSH, tokeny cloud (AWS, GCP, Azure) oraz credentials z lokalnych plików konfiguracyjnych.
Po zakończeniu zadania skrypt sam się kasował i podmieniał swój własny plik package.json na czystą wersję, żeby utrudnić wykrycie po fakcie.
Atak na axios nie był wymierzony w serwery produkcyjne. Był wymierzony w deweloperów: ich klucze, tokeny i dostępy. Ofiara mogła przez miesiące nie wiedzieć, że ktoś ma klucze do jej infrastruktury.
Skrypt był przygotowany z osobnymi payloadami dla każdego systemu operacyjnego, co potwierdza, że za atakiem stali profesjonaliści ze sprecyzowanym celem.
Czy mój projekt jest zagrożony? Jak sprawdzić i co zrobić
Zagrożone są projekty, które w nocy z 30 na 31 marca 2026 wykonały npm install, npm update lub odpalały automatyczny build CI/CD. Zainfekowane wersje to axios@1.14.1 i axios@0.30.4. Bezpieczna wersja to axios@1.14.0 (lub axios@0.30.3 dla starszej gałęzi).
Jak sprawdzić zainstalowaną wersję:
npm list axios
Jeśli widzisz 1.14.1 lub 0.30.4, zastosuj kroki rekomendowane przez zespół axios i Vercel:
- Zainstaluj bezpieczną wersję:
npm install axios@1.14.0 - Usuń ręcznie katalog
node_modules/plain-crypto-js - Przeinstaluj zależności:
npm install --ignore-scripts - Sprawdź logi CI/CD: czy któryś build uruchomił się między 23:59 a 03:00 UTC
Flaga --ignore-scripts blokuje uruchamianie skryptów postinstall przy instalacji pakietów. W normalnych warunkach byłaby uciążliwa, ale po incydencie takiego kalibru warto jej użyć jako środka ostrożności przynajmniej jednorazowo.
Jeśli pobrałeś zainfekowaną wersję, rozważ rotację kluczy SSH i tokenów API, szczególnie dla środowisk cloud.
Jak atak wyszedł na jaw i jak szybko go naprawiono?
Platforma Socket.dev, która automatycznie skanuje npm pod kątem złośliwego kodu, wykryła plain-crypto-js@4.2.1 w ciągu 6 minut od publikacji: pakiet pojawił się o 23:59:12, detekcja nastąpiła o 00:05:41 UTC. To szybka reakcja, ale i tak zostawiła otwarte okno ataku trwające około trzech godzin, zanim npm zdążył wycofać zainfekowane wersje.
Firma StepSecurity opublikowała pierwszy szczegółowy raport techniczny. Zespół axios otworzył publiczny wątek na GitHubie (issue #10604) żeby komunikować się z użytkownikami. Vercel wydał osobny changelog z krokami remediation, bo infrastruktura Vercela intensywnie używa axios. W Polsce pierwszy alarm podniósł Niebezpiecznik.pl, ostrzegając deweloperów żeby sprawdzili wersje i zwrócili szczególną uwagę na overnight automatyczne buildy.
Axios uruchomił też workflow deprecacji na npm, formalnie oznaczając zainfekowane wersje jako wycofane, żeby żaden package manager nie pobierał ich już automatycznie.
Piszemy automatyzacje, webhooki i agenty AI, które często pracują w nocy i wykonują buildy bez nadzoru człowieka. Jeśli jedno z nich pobrało zainfekowaną wersję axios między północą a trzecią w nocy, mogło to zrobić bez żadnego alertu. To dokładnie ta sama logika co boty i automaty odpowiadające za ponad połowę ruchu w internecie. Nikt tego nie widzi, dopóki nie zaczniemy szukać.
Kurs n8n 2.0 · Kodożercy
Automatyzacja to dziś jedna z najbardziej poszukiwanych umiejętności
Firmy szukają ludzi którzy łączą procesy z narzędziami AI. Kurs n8n 2.0 na Kodożercach da Ci praktyczne umiejętności (od webhooków po agenty AI), które możesz pokazać już jutro.
Zobacz program kursu →
FAQ: najczęstsze pytania o atak na axios npm
Czy axios jest teraz bezpieczny do użycia?
Tak. npm wycofał zainfekowane wersje, a axios@1.14.0 jest bezpieczna i niezmodyfikowana. Zespół axios pracuje nad wdrożeniem dodatkowych zabezpieczeń procesu wydawania nowych wersji, żeby podobna sytuacja nie mogła się powtórzyć.
Jak doszło do przejęcia konta maintainera axios?
Atakujący zdobył dane logowania jednego z głównych maintainerów. Po uzyskaniu dostępu zmienił adres e-mail konta na anonimowy adres ProtonMail, co utrudniło szybką reakcję. Atakujący działał poza standardowym pipeline CI/CD projektu, publikując paczki bezpośrednio przez npm CLI.
Co to jest atak na łańcuch dostaw npm?
Atak na łańcuch dostaw npm (supply chain attack) to rodzaj ataku, w którym zamiast atakować bezpośrednio Twój kod, atakujący kompromituje bibliotekę zewnętrzną, od której zależy Twój projekt. Ponieważ zależności instalujesz automatycznie poleceniem npm install, złośliwy kod trafia na Twoją maszynę bez żadnego ostrzeżenia. Ataki tego rodzaju są groźne, bo jeden przejęty pakiet z milionami pobrań tygodniowo jest w stanie dotrzeć do setek tysięcy projektów jednocześnie.
{ aplikacje webowe }Masz pomysł na aplikację? Najpierw go zobacz
Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.
Podsumowanie
Atak na axios z 31 marca 2026 roku to podręcznikowy przykład supply chain attack na ekosystem npm. Przejęte konto maintainera, złośliwy RAT z funkcją samozniszczenia, trzy godziny okna ataku i miliony automatycznych instalacji w CI/CD tworzą scenariusz, który uderza w najsłabszy punkt deweloperów: zaufanie do bibliotek, z których korzystają każdego dnia. Sprawdź wersję axios w swoim projekcie, zrotuj klucze SSH i tokeny cloud jeśli byłeś w oknie ataku, i potraktuj flagę --ignore-scripts jako domyślne zabezpieczenie po incydentach tego typu.
