Wprowadzenie do problemu / definicja
Atak na łańcuch dostaw systemu to scenariusz, w którym napastnik kompromituje element procesu tworzenia lub dystrybucji aplikacji zamiast atakować bezpośrednio organizację docelową. W ekosystemie JavaScript szczególnie niebezpieczne są incydenty związane z rejestrem npm, ponieważ pojedyncza złośliwa zależność może zostać automatycznie pobrana do środowisk deweloperskich, pipeline’ów CI/CD oraz systemów produkcyjnych.
Przypadek dotyczący biblioteki Axios pokazuje, iż przejęcie konta maintainera i publikacja skażonych wersji pakietu może doprowadzić do uruchomienia złośliwego kodu na Windows, macOS i Linuksie bez konieczności ingerowania w główną logikę samej biblioteki.
W skrócie
- Złośliwe wersje Axios 1.14.1 oraz 0.30.4 zostały opublikowane z użyciem przejętego konta npm maintainera.
- Skażone wydania dodawały zależność plain-crypto-js@4.2.1, której celem było uruchomienie skryptu postinstall.
- Mechanizm działał jako dropper wieloplatformowego RAT-a dla Windows, macOS i Linuksa.
- Atak był trudniejszy do wykrycia, ponieważ nie wymagał modyfikacji kodu źródłowego Axios.
Kontekst / historia
Axios należy do najpopularniejszych klientów HTTP w ekosystemie JavaScript i jest szeroko używany zarówno w projektach frontendowych, jak i backendowych. Z tego powodu kompromitacja tego pakietu ma potencjalnie bardzo szeroki zasięg i może dotyczyć tysięcy środowisk budowania oraz wdrożeń.
Z opisu incydentu wynika, iż najpierw opublikowano pozornie niegroźną wersję pakietu plain-crypto-js@4.2.0, a następnie wersję 4.2.1 zawierającą złośliwy ładunek. Dopiero później do rejestru trafiły skażone wydania Axios, które dodawały tę zależność do drzewa instalacji. Taka sekwencja wskazuje na zaplanowaną operację, w której napastnik przygotował elementy ataku z wyprzedzeniem.
Istotne jest również to, iż publikacja została wykonana z wykorzystaniem przejętych poświadczeń do konta npm maintainera. Oznacza to, iż atak ominął wiele klasycznych sygnałów ostrzegawczych związanych z nieautoryzowaną modyfikacją repozytorium lub procesu CI/CD projektu.
Analiza techniczna
Sercem ataku było dodanie zależności, która nie była potrzebna do działania biblioteki w normalnym czasie wykonania. Jej jedynym zadaniem było uruchomienie złośliwego kodu podczas instalacji pakietu z użyciem mechanizmu postinstall. To dobrze znany wzorzec nadużycia lifecycle scripts w npm, ponieważ pozwala wykonać kod automatycznie już na etapie pobierania zależności.
Dropper został zaimplementowany w Node.js i po uruchomieniu rozpoznawał system operacyjny ofiary. Następnie pobierał odpowiedni drugi etap infekcji zależnie od platformy:
- na macOS pobierany był skompilowany binarny RAT,
- na Windows wykorzystywano łańcuch oparty o PowerShell i VBScript,
- na Linuksie pobierany był skrypt RAT w Pythonie.
Wariant dla macOS zapisywał binarium w katalogu cache i uruchamiał je w tle. Wersja windowsowa kopiowała interpreter PowerShell pod mylącą nazwą, a następnie uruchamiała skrypt odpowiedzialny za pobranie i wykonanie adekwatnego ładunku. Wariant linuksowy zapisywał skrypt w katalogu tymczasowym i uruchamiał go z użyciem nohup, aby proces przetrwał zakończenie sesji instalacyjnej.
Wszystkie trzy warianty korzystały ze spójnego modelu komunikacji z infrastrukturą C2 i oferowały podobny zestaw możliwości operacyjnych. Obejmowały one rozpoznanie środowiska, wykonywanie poleceń powłoki, pobieranie dodatkowych ładunków, enumerację systemu plików oraz zdalne sterowanie hostem. W systemie Windows zaobserwowano również mechanizm trwałości uruchamiany przy logowaniu użytkownika.
Na uwagę zasługuje również warstwa antyforensic. Po wykonaniu droppera złośliwy pakiet usuwał ślady swojej aktywności, w tym elementy wskazujące na uruchomienie postinstall, a następnie podmieniał manifest na czystą wersję. Taki zabieg znacząco utrudniał analizę incydentu i mógł sprawić, iż lokalna inspekcja katalogu node_modules nie ujawniała od razu źródła kompromitacji.
Konsekwencje / ryzyko
Skala ryzyka jest wysoka, ponieważ Axios jest powszechnie obecny w projektach aplikacyjnych i często trafia do środowisk automatycznego budowania. To oznacza, iż zagrożenie mogło dotyczyć nie tylko stacji roboczych programistów, ale także runnerów CI/CD, środowisk testowych, kontenerów budowanych w pipeline’ach oraz serwerów aplikacyjnych.
Jeżeli skażona wersja została zainstalowana w środowisku posiadającym dostęp do sekretów, napastnik mógł uzyskać tokeny API, klucze chmurowe, poświadczenia do rejestrów pakietów, a choćby dane dostępowe do systemów produkcyjnych. Dodatkowo aktywna komunikacja z C2 stwarzała warunki do dalszej rozbudowy kompromitacji, wdrażania kolejnych narzędzi i kradzieży danych.
W środowiskach przedsiębiorstw ryzyko obejmuje również lateral movement, zwłaszcza jeżeli zainfekowany host miał połączenie z wewnętrznymi repozytoriami, serwerami budowania lub systemami zarządzania sekretami. Incydent podważa też zaufanie do podstawowych mechanizmów bezpieczeństwa open source, ponieważ złośliwość została ukryta w zależności tranzytywnej aktywowanej podczas instalacji, a nie przez kod biznesowy biblioteki.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy w którymkolwiek środowisku zostały zainstalowane wersje Axios 1.14.1 lub 0.30.4. jeżeli tak, taki system należy traktować jako potencjalnie skompromitowany i objąć procedurą reagowania na incydent.
- obniżyć wersję Axios do bezpiecznego wydania i usunąć złośliwą zależność z lokalnych instalacji,
- przeprowadzić rotację sekretów oraz poświadczeń dostępnych z poziomu narażonych hostów,
- przeszukać systemy pod kątem artefaktów charakterystycznych dla Windows, macOS i Linuksa,
- przeanalizować logi instalacji zależności i uruchomień buildów z okresu ekspozycji,
- zweryfikować ruch wychodzący pod kątem komunikacji z infrastrukturą napastnika,
- odtworzyć obrazy runnerów CI/CD i środowisk buildowych, jeżeli mogły instalować skażone pakiety,
- zablokować wykonywanie nieautoryzowanych skryptów preinstall, install i postinstall,
- wzmocnić ochronę kont maintainerów przez silne uwierzytelnianie i ograniczenie długowiecznych tokenów publikacyjnych.
Z perspektywy strategicznej warto wdrożyć wielowarstwowe zabezpieczenia dla ekosystemu zależności, w tym kontrolę integralności lockfile, monitoring zmian w zależnościach bezpośrednich i tranzytywnych, sandboxing procesów budowania oraz ograniczanie dostępu runnerów do wrażliwych zasobów.
Podsumowanie
Atak na Axios jest jednym z najpoważniejszych przykładów kompromitacji łańcucha dostaw w ekosystemie JavaScript. Połączył przejęcie konta maintainera, publikację złośliwej zależności oraz automatyczne uruchamianie malware podczas instalacji pakietu, co znacząco zwiększyło skuteczność operacji.
Najważniejsza lekcja z tego incydentu jest jasna: bezpieczeństwo projektu open source nie kończy się na analizie kodu źródłowego. Równie istotne są proces publikacji, ochrona kont maintainerów, kontrola drzewa zależności oraz obserwacja zachowań wykonywanych na etapie instalacji. Dla zespołów bezpieczeństwa i DevSecOps oznacza to konieczność traktowania środowisk buildowych jako zasobów wysokiego ryzyka.
Źródła
- The Hacker News – Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account — https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html
- StepSecurity – Malicious versions of Axios published to npm — https://www.stepsecurity.io/blog/malicious-versions-of-axios-published-to-npm
- Elastic Security Labs – Guidance and technical analysis related to the Axios npm compromise — https://www.elastic.co/security-labs
- Huntress – Research notes on the Axios npm malware activity — https://www.huntress.com/blog
- Socket – Analysis of additional packages distributing the same payload — https://socket.dev