Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem npm od lat pozostaje jednym z kluczowych elementów współczesnego łańcucha dostaw oprogramowania. Jednocześnie jego otwarty charakter sprawia, że popularne pakiety stają się atrakcyjnym celem dla atakujących, którzy mogą wykorzystać zaufanie deweloperów do legalnych bibliotek.
Incydent związany z pakietem node-ipc pokazuje, że zagrożenie nie musi wynikać z fałszywego pakietu czy literówki w nazwie. W tym przypadku problemem były złośliwe wersje opublikowane pod prawidłową nazwą znanej biblioteki, co znacząco zwiększało szansę na skuteczną kompromitację środowisk developerskich oraz pipeline’ów CI/CD.
W skrócie
14 maja 2026 roku ujawniono, że wersje 9.1.6, 9.2.3 oraz 12.0.1 pakietu node-ipc dostępne w npm zawierały złośliwy komponent typu stealer i backdoor. Kod był uruchamiany podczas zwykłego załadowania biblioteki przez aplikację, bez potrzeby korzystania z typowych skryptów instalacyjnych.
Ładunek zbierał szeroki zakres sekretów z systemu ofiary, w tym poświadczenia chmurowe, klucze SSH, tokeny Kubernetes, dane konfiguracyjne narzędzi developerskich oraz artefakty wykorzystywane w procesach automatyzacji i wdrożeń. Zebrane informacje były następnie przygotowywane do eksfiltracji na infrastrukturę kontrolowaną przez atakującego.
Kontekst / historia
node-ipc to znany pakiet dla środowiska Node.js, wykorzystywany do komunikacji międzyprocesowej. Projekt był już wcześniej kojarzony z kontrowersjami bezpieczeństwa, co sprawia, że jego ponowne pojawienie się w kontekście incydentu supply chain zwróciło szczególną uwagę badaczy.
Tym razem analiza wskazała, że złośliwe wydania zostały opublikowane przez konto atiertant, widoczne na liście maintainerów pakietu. Może to sugerować przejęcie uprawnień publikacyjnych albo wcześniejsze dodanie maintainera, którego konto zostało następnie użyte do dystrybucji skażonych wersji. Atak był tym bardziej niebezpieczny, że wykorzystano rozpoznawalny, legalny pakiet, a nie jego podróbkę.
Analiza techniczna
Najistotniejszą cechą techniczną ataku był sposób uruchamiania złośliwego kodu. Zamiast wykorzystywać skrypty preinstall, install lub postinstall, które często są monitorowane przez narzędzia bezpieczeństwa, payload został osadzony bezpośrednio w pliku node-ipc.cjs jako natychmiastowo wykonywane wyrażenie funkcyjne. Oznacza to, że aktywacja następowała już przy require('node-ipc').
Po uruchomieniu malware przeprowadzał fingerprinting hosta i rozpoczynał enumerację lokalnych zasobów. Badacze wskazali, że kod poszukiwał około 90 kategorii danych, obejmujących m.in.:
- poświadczenia AWS, Azure i Google Cloud,
- klucze SSH i konfiguracje GitHub CLI,
- tokeny Kubernetes,
- pliki Terraform oraz dane środowisk IaC,
- ustawienia narzędzi AI i IDE,
- historię poleceń powłoki oraz wybrane dane aplikacyjne.
Następnie zebrane informacje były kompresowane w formacie GZIP, dzielone na fragmenty i przygotowywane do eksfiltracji. Opisano co najmniej dwa kanały wyprowadzania danych: żądania HTTPS do domeny podszywającej się pod usługi chmurowe oraz transmisję przez DNS z użyciem zapytań TXT. Dodatkowo malware modyfikował ustawienia resolvera, co mogło utrudniać wykrycie anomalii przez standardowy monitoring.
Istotna była też różnica między liniami wersji. Wersja 12.0.1 zawierała mechanizm warunkowego uruchamiania oparty na porównaniu skrótu SHA-256, co może wskazywać na próbę selektywnego targetowania. Z kolei warianty z linii 9.x według analiz wykonywały pełny ładunek szerzej, bez podobnych ograniczeń.
Konsekwencje / ryzyko
Ryzyko wynikające z tego incydentu należy ocenić jako wysokie, zwłaszcza dla organizacji, które używały node-ipc w środowiskach developerskich, systemach buildowych lub pipeline’ach CI/CD. Wyciek sekretów z takich miejsc może prowadzić do dalszego przejęcia repozytoriów, modyfikacji procesów wdrożeniowych, nadużyć w środowiskach chmurowych oraz kolejnych etapów kompromitacji łańcucha dostaw.
Szczególnie niebezpieczne jest to, że aktywacja następowała przy imporcie biblioteki, a nie podczas instalacji. Taki model działania mógł ominąć część zabezpieczeń skoncentrowanych na hookach pakietów npm. Dodatkowo wykorzystanie DNS jako kanału eksfiltracji utrudniało zauważenie incydentu na poziomie monitoringu sieciowego.
Rekomendacje
Organizacje powinny w pierwszej kolejności sprawdzić, czy w projektach, lockfile’ach, cache zależności, artefaktach buildów oraz logach pipeline’ów pojawiały się wersje 9.1.6, 9.2.3 lub 12.0.1. Jeżeli tak, środowisko należy traktować jako potencjalnie skompromitowane.
- usunąć złośliwe wersje pakietu i przejść na zweryfikowane, czyste wydania,
- przeprowadzić pełną rotację wszystkich sekretów dostępnych w czasie instalacji lub uruchomienia pakietu,
- przeanalizować logi CI/CD pod kątem nietypowych uruchomień i zmian w workflow,
- zweryfikować aktywność w usługach chmurowych i operacje wykonane przez powiązane tożsamości IAM,
- skontrolować ruch DNS i HTTPS pod kątem anomalii oraz potencjalnej komunikacji z infrastrukturą atakującego,
- wdrożyć pinowanie wersji, kontrolę lockfile i monitoring behawioralny zależności open source,
- przejrzeć polityki publikacyjne oraz listy maintainerów własnych pakietów.
W dłuższej perspektywie warto ograniczać liczbę sekretów dostępnych w runnerach CI/CD, stosować krótkotrwałe tokeny oraz rozdzielać środowiska build, testów i publikacji. Ten incydent pokazuje, że samo usunięcie podatnej paczki nie wystarcza, jeśli mogło dojść do ujawnienia poświadczeń.
Podsumowanie
Przypadek node-ipc to kolejny przykład zaawansowanego ataku na software supply chain, w którym przeciwnik wykorzystał zaufanie do prawidłowego, popularnego pakietu npm. Złośliwe wersje działały jak stealer i backdoor, koncentrując się na sekretach deweloperskich, zasobach chmurowych oraz danych z pipeline’ów CI/CD.
Najważniejszy wniosek dla zespołów bezpieczeństwa jest jasny: w przypadku incydentów dotyczących zależności open source trzeba zakładać możliwość wycieku poświadczeń i reagować szerzej niż tylko przez usunięcie pakietu. Kluczowe są szybka identyfikacja ekspozycji, pełna rotacja sekretów i dokładna analiza wpływu na cały łańcuch dostaw oprogramowania.
Źródła
- The Hacker News — https://thehackernews.com/2026/05/stealer-backdoor-found-in-3-node-ipc.html
- StepSecurity: Active Supply Chain Attack: Malicious node-ipc Versions Published to npm — https://www.stepsecurity.io/blog/node-ipc-npm-supply-chain-attack
- npm: node-ipc package page — https://www.npmjs.com/package/node-ipc
- npm: node-ipc version 12.0.0 — https://www.npmjs.com/package/node-ipc/v/12.0.0?activeTab=versions
- Socket: node-ipc package versions — https://socket.dev/npm/package/node-ipc/versions