Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent związany z pakietem axios pokazuje, że współczesne ataki na łańcuch dostaw oprogramowania coraz częściej zaczynają się nie od błędu w kodzie, lecz od skutecznej kompromitacji człowieka i jego środowiska pracy. W tym przypadku napastnicy przejęli konto maintainera popularnej biblioteki publikowanej w npm, wykorzystując starannie przygotowaną kampanię socjotechniczną opartą na fałszywym komunikacie o problemie z Microsoft Teams.
Skutkiem było opublikowanie złośliwych wersji pakietu, które zawierały dodatkową zależność instalującą malware. To klasyczny przykład ataku supply chain, w którym zaufany kanał dystrybucji staje się nośnikiem zagrożenia dla tysięcy projektów i środowisk developerskich.
W skrócie
- Złośliwe wersje axios 1.14.1 oraz 0.30.4 zostały opublikowane 31 marca 2026 r.
- Do wydań dodano zależność plain-crypto-js, wykorzystywaną do dostarczenia zdalnego trojana.
- Zagrożenie obejmowało systemy macOS, Windows i Linux.
- Pakiety były dostępne przez około trzy godziny, zanim zostały usunięte z rejestru.
- Atak miał charakter ukierunkowany i wpisywał się w szerszą kampanię wymierzoną w maintainerów projektów Node.js.
Kontekst / historia
Axios należy do najpopularniejszych bibliotek HTTP w ekosystemie JavaScript i Node.js, dlatego każda kompromitacja związana z tym pakietem automatycznie zyskuje wysoki priorytet bezpieczeństwa. Z dostępnych analiz wynika, że przygotowania do ataku rozpoczęły się około dwóch tygodni przed publikacją złośliwych wersji.
Napastnicy podszyli się pod wiarygodną firmę, odtworzyli jej identyfikację wizualną, przygotowali fałszywe profile pracowników i zaprosili ofiarę do spreparowanego środowiska komunikacyjnego. Następnie zorganizowali spotkanie online wyglądające jak standardowa rozmowa biznesowa. W trakcie połączenia ofiara zobaczyła komunikat sugerujący problem techniczny w Teams oraz potrzebę uruchomienia rzekomej poprawki. To właśnie ten etap doprowadził do uruchomienia złośliwego oprogramowania i przejęcia dostępu do środowiska maintainera.
Istotne jest także to, że podobne próby zgłaszali inni maintainerzy i osoby związane z projektami open source. Sugeruje to powtarzalny model operacyjny, nastawiony na kompromitację kont o wysokim znaczeniu dla ekosystemu Node.js.
Analiza techniczna
Atak nie polegał na modyfikacji repozytorium źródłowego axios. Zamiast tego napastnicy wykorzystali przejęte uprawnienia do publikacji w npm i przygotowali legalnie wyglądające wydania zawierające dodatkową, złośliwą zależność. To szczególnie groźna technika, ponieważ może ominąć część kontroli bezpieczeństwa skupionych głównie na commitach, pull requestach i przeglądzie kodu.
W opublikowanych wersjach 1.14.1 oraz 0.30.4 dodano pakiet plain-crypto-js w wersjach 4.2.0 lub 4.2.1. Komponent ten odpowiadał za dostarczenie trojana zdalnego dostępu działającego wieloplatformowo. W praktyce oznaczało to możliwość uruchomienia złośliwego kodu zarówno na stacjach roboczych programistów, jak i na hostach CI/CD, jeśli w czasie ekspozycji wykonywano instalację zależności.
Kluczowym elementem incydentu było przejęcie uwierzytelnionej sesji i lokalnych zasobów urządzenia ofiary. W takiej sytuacji nawet MFA nie zapewnia pełnej ochrony, ponieważ malware działające na końcówce może przejmować tokeny, cookies sesyjne, dane przeglądarki, sekrety zapisane lokalnie oraz poświadczenia wykorzystywane przez pipeline’y publikacyjne i buildowe.
W analizach po incydencie pojawiły się również wskaźniki kompromitacji związane z infrastrukturą C2, w tym domena sfrclak[.]com, adres IP 142.11.206.73 oraz odniesienia do malware określanego jako WAVESHAPER.V2. Pojawiły się też powiązania atrybucyjne z aktorem UNC1069, co wzmacnia ocenę, że była to dojrzała operacja ukierunkowana, a nie prosty phishing nastawiony wyłącznie na kradzież hasła.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko wynika z roli axios w łańcuchu zależności. Biblioteka jest szeroko stosowana bezpośrednio i pośrednio w aplikacjach webowych, usługach backendowych, narzędziach developerskich i procesach automatyzacji. Nawet krótki okres dostępności złośliwych wydań mógł wystarczyć, aby pakiety zostały pobrane przez środowiska korzystające z automatycznych instalacji.
Dla organizacji oznacza to kilka poziomów zagrożenia. Po pierwsze, mogło dojść do kompromitacji stacji deweloperskich i runnerów CI. Po drugie, narażone były sekrety przechowywane w plikach konfiguracyjnych, zmiennych środowiskowych i lokalnych magazynach poświadczeń. Po trzecie, taki incydent może prowadzić do dalszego ruchu bocznego: przejęcia repozytoriów kodu, systemów artefaktów, kont chmurowych lub kolejnych pakietów publikowanych przez organizację.
Dodatkowym problemem jest trudność w odtworzeniu pełnej skali ekspozycji. Jeśli firma nie przechowuje historii lockfile, logów instalacji pakietów oraz telemetrii z hostów buildowych, ustalenie rzeczywistego wpływu incydentu może być bardzo trudne. Samo usunięcie złośliwego pakietu z rejestru nie oznacza końca zagrożenia, jeśli malware zdążyło już wykraść poświadczenia lub pobrać kolejne ładunki.
Rekomendacje
Organizacje, które mogły pobrać wskazane wersje axios, powinny traktować ten incydent jako potencjalną kompromitację hosta, a nie wyłącznie problem z pojedynczą zależnością. Reakcja powinna objąć zarówno analizę pakietów, jak i pełne dochodzenie na poziomie systemów końcowych oraz pipeline’ów.
- Zidentyfikować instalacje axios 1.14.1 i 0.30.4 oraz obecność plain-crypto-js.
- Usunąć złośliwe artefakty i przejść na bezpieczne wersje pakietu.
- Przeprowadzić rotację wszystkich sekretów, tokenów, kluczy API i poświadczeń dostępnych na potencjalnie zagrożonych hostach.
- Zweryfikować logi sieciowe pod kątem komunikacji z infrastrukturą C2.
- Odtworzyć z zaufanego źródła maszyny, na których mogło dojść do wykonania złośliwego kodu.
- Sprawdzić, czy z zagrożonych środowisk nie publikowano innych pakietów, buildów lub artefaktów.
W szerszej perspektywie warto ograniczyć zależność procesu publikacji od prywatnych stacji roboczych maintainerów. Dobrą praktyką są odseparowane i utwardzone środowiska release, niezmienne pipeline’y publikacyjne, przypinanie wersji zależności oraz monitoring nietypowych publikacji w rejestrach pakietów. Równie ważne są szkolenia dotyczące nowoczesnej socjotechniki, obejmujące fałszywe spotkania online, komunikaty o błędach i scenariusze podszywania się pod partnerów biznesowych.
Podsumowanie
Atak na axios stanowi podręcznikowy przykład nowoczesnego zagrożenia dla łańcucha dostaw open source. Kluczowym elementem nie była luka w samej bibliotece, lecz skuteczna kompromitacja maintainera przy użyciu zaawansowanej socjotechniki i malware uruchomionego pod pretekstem naprawy błędu komunikatora.
Dla branży to wyraźny sygnał, że samo zabezpieczenie repozytorium i wdrożenie MFA nie wystarczą, jeśli przejęta zostanie końcówka dewelopera. Największą wartość obronną zapewniają dziś segmentacja procesu publikacji, pełna widoczność telemetrii, szybka reakcja na incydenty oraz traktowanie maintainerów projektów o dużym zasięgu jako celów wysokiego ryzyka.
Źródła
- BleepingComputer — https://www.bleepingcomputer.com/news/security/axios-npm-hack-used-fake-teams-error-fix-to-hijack-maintainer-account/
- Post Mortem: axios npm supply chain compromise · Issue #10636 · axios/axios · GitHub — https://github.com/axios/axios/issues/10636
- Google Cloud Blog — North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack — https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package
- Socket — Attackers Are Hunting High-Impact Node.js Maintainers in a Coordinated Social Engineering Campaign — https://socket.dev/blog/attackers-hunting-high-impact-nodejs-maintainers