Atak na bibliotekę node-ipc. Jak zabezpieczyć środowisko programistyczne przed supply chain

14 maja 2026 roku zespół CERT Polska poinformował o ataku typu supply chain na popularną bibliotekę dla środowiska Node.js – node-ipc. W wyniku przejęcia konta opiekuna projektu do oficjalnego repozytorium npm trafiły zmodyfikowane wersje pakietu. Szkodliwy kod został zaprojektowany tak, by nie zakłócać działania aplikacji, a jego celem była kradzież poświadczeń programistów, tokenów CI/CD, kluczy SSH oraz danych ze środowisk chmurowych i klastrów Kubernetes. Atakujący wykorzystali nietypową metodę eksfiltracji – zapytania DNS TXT do publicznych serwerów.

Incydent dotyczy przede wszystkim zespołów developerskich, administratorów infrastruktury oraz firm korzystających z node-ipc jako zależności w swoich projektach. W artykule wyjaśniamy, jak działało zagrożenie, które wersje są niebezpieczne i jakie kroki należy podjąć, aby sprawdzić, czy nasze systemy nie zostały skompromitowane.

Szczegóły ataku – jak działał złośliwy kod

Jak podaje CERT Polska w komunikacie nr 74/2026, szkodliwy kod ukryto w pliku node-ipc.cjs. Jest on automatycznie uruchamiany przy każdym wywołaniu require('node-ipc'). Atakujący opublikowali trzy skażone wersje: 9.2.0, 9.2.1 oraz 9.2.2. Kod działał w tle – nie powodował błędów ani widocznych opóźnień, co znacząco utrudniało jego wykrycie podczas standardowego przeglądu kodu czy testów.

Mechanizm ataku polegał na zbieraniu danych z zainfekowanego środowiska: poświadczeń programistycznych, tokenów CI/CD, kluczy SSH oraz konfiguracji chmurowych i Kubernetes. Następnie informacje te były eksfiltrowane za pomocą zapytań DNS TXT kierowanych do publicznych serwerów DNS (1.1.1.1 oraz 8.8.8.8). Zapytania dotyczyły domen utworzonych według ściśle określonego schematu, który umożliwiał odtworzenie przechwyconych danych po stronie atakującego. CERT Polska opublikował listę wskaźników kompromitacji (IoC), którą zamieściliśmy poniżej.

Lista wskaźników kompromitacji – co sprawdzić

Zespół CERT Polska udostępnił następujące wskaźniki, które mogą świadczyć o obecności zagrożenia w środowisku:

• Domeny C2 i eksfiltracji: azurestaticprovider[.]net (C2) oraz bt.node[.]js (domena używana do eksfiltracji danych)
• Adresy IP: 37.5.69
• Hashe plików:
  • SHA-256: 96097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144
  • MD5: d1ba0419cb5e5cb5e5de91b9b58e87b8322e1

  Administratorzy powinni niezwłocznie sprawdzić, czy w logach DNS nie pojawiły się zapytania do wymienionych domen. Warto również przejrzeć repozytoria kodu i pliki lock (package-lock.json, yarn.lock) w poszukiwaniu zależności od wersji 9.2.0, 9.2.1 oraz 9.2.2 pakietu node-ipc. W przypadku ich wykrycia CERT Polska prosi o kontakt zespołem.

  Jak zabezpieczyć środowisko programistyczne

  Ataki typu supply chain na ekosystem npm stają się coraz częstsze. W ubiegłym roku podobne incydenty dotknęły m.in. biblioteki colors i faker. Choć nie da się całkowicie wyeliminować ryzyka, można je znacząco ograniczyć poprzez wdrożenie kilku dobrych praktyk.

  Po pierwsze, warto stosować narzędzia do skanowania zależności pod kątem znanych podatności, takie jak npm audit, Snyk czy GitHub Dependabot. Powinny one być uruchamiane automatycznie w pipeline CI/CD. Po drugie, dla krytycznych projektów rozważne jest użycie lockfajlów (package-lock.json) oraz ich weryfikacja – na przykład poprzez porównanie sum kontrolnych z zaufanym źródłem. Po trzecie, ograniczenie uprawnień tokenów CI/CD i stosowanie tymczasowych, krótkożyjących poświadczeń zmniejsza potencjalny zysk atakującego w przypadku wycieku.

  W kontekście samego ataku na node-ipc kluczowe jest również monitorowanie nietypowej komunikacji DNS. Filtrowanie zapytań DNS TXT na poziomie firewalla czy serwera DNS może pomóc w szybkim wykryciu ewentualnej eksfiltracji. Warto rozważyć implementację DNS-over-HTTPS lub DNS-over-TLS z logiem, które utrudniają wyciek danych przez ten kanał.

  Ograniczenia informacji – co jeszcze nie jest znane

  Na chwilę publikacji komunikatu CERT Polska nie podał, ile projektów lub organizacji mogło zostać dotkniętych atakiem. Nie wiadomo również, jak długo skażone wersje były dostępne w npm przed ich usunięciem. Brak jest informacji o tym, czy atakujący zdołał wykorzystać skradzione dane do dalszych włamań. Zespół CERT nie wskazuje też, jak doszło do przejęcia konta opiekuna – mogło to być skutki phishing, wycieku hasła lub ataku na infrastrukturę uwierzytelniania wieloskładnikowego.

  Te niewiadome podkreślają, jak ważne jest zachowanie czujności i szybka reakcja na tego typu ostrzeżenia. Nawet jeśli w naszym środowisku nie znaleziono bezpośrednich wskaźników, warto potraktować ten incydent jako impuls do przeglądu polityk bezpieczeństwa w łańcuchu dostaw oprogramowania.

  Co dalej – jak reagować odpowiedzialnie

  Zalecenie CERT Polska jest jednoznaczne: niezwłoczna weryfikacja systemów pod kątem podanych wskaźników i podejrzanej komunikacji DNS. Jeżeli podczas audytu natkniesz się na skażone wersje lub nietypowe zapytania DNS, skontaktuj się zespołem CERT Polska. Nie próbuj samodzielnie analizować złośliwego pliku ani przeprowadzać działań ofensywnych – bezpieczniej jest poprosić o pomoc specjalistów.

  Dla zespołów programistycznych i administratorów najważniejszym wnioskiem z tego incydentu jest konieczność traktowanie każdej zależności zewnętrznej jako potencjalnego wektora ataku. Regularne audyty zależności, ograniczanie uprawnień i monitorowanie anomalii sieciowych to fundamenty ochrony przed supply chain. W dłuższej perspektywie warto rozważyć utworzenie wewnętrznego rejestru pakietów czy mirroru npm z zatwierdzonymi wersjami pakietów, co daje większą kontrolę nad tym, co trafia do produkcji.

  Atak na node-ipc to kolejne potwierdzenie, że bezpieczeństwo ekosystemu open source wymaga ciągłej uwagi. Bez paniki, ale z konkretnymi działaniami – to najlepsza odpowiedź na zagrożenie.

  Artykuł powstał na podstawie komunikatu CERT Polska z 15 maja 2026 roku.