Atak na łańcuch dostaw npm: nowa fala infekcji i co oznacza dla polskich firm
Kampania TeamPCP przeszła w nową fazę. Skradzione tokeny CI/CD, podrobione pakiety i framework udostępniony publicznie – wyjaśniamy, jak się bronić przed falą ataków na łańcuch dostaw.
Kampania TeamPCP, która wstrząsnęła ekosystemem open source, weszła w nową, bardziej niebezpieczną fazę. To, co zaczęło się jako ukierunkowany atak na łańcuch dostaw, przerodziło się w rozproszoną falę infekcji, której skutki mogą dotknąć każdego programistę i firmę korzystającą z pakietów npm. W ciągu ostatnich dwóch tygodni doszło do kompromitacji pakietów Red Hat, platformy Vapi oraz formalnej reakcji amerykańskiej agencji CISA. Co to oznacza dla polskich użytkowników i jak się chronić?
Nowa fala ataków: od Red Hat po Vapi
Od 1 czerwca 2026 roku obserwujemy gwałtowny wzrost aktywności związanej z kampanią TeamPCP. Jak opisuje SANS Internet Storm Center, pierwszym znaczącym incydentem była kompromitacja pakietów w zakresie @redhat-cloud-services. Firma Wiz nazwała tę kampanię „Miasma” – atakujący wykorzystali skradzione konto pracownika Red Hat na GitHubie, aby wstrzyknąć złośliwe workflowy GitHub Actions. W efekcie opublikowano co najmniej 32 pakiety (w ponad 90 wersjach) z kradnącym dane kodem, które łącznie miały około 80 tysięcy tygodniowych pobrań.
Zaledwie dwa dni później, 3 czerwca, pojawił się wariant nazwany „Phantom Gyp”. Jak podaje BleepingComputer, w ciągu dwóch godzin skompromitowano 57 dodatkowych pakietów w 286 złośliwych wersjach. Największym celem był pakiet @vapi-ai/server-sdk – oficjalne SDK platformy Vapi.ai, pobierane ponad 408 tysięcy razy miesięcznie. Nowa technika polegała na wykorzystaniu plików binding.gyp do uruchomienia złośliwego kodu podczas instalacji, co omijało standardowe monitorowanie skryptów w package.json.
Reakcja CISA i problem z atrybucją
27 maja 2026 roku amerykańska agencja CISA dodała trzy podatności do swojego katalogu KEV (Known Exploited Vulnerabilities), w tym CVE-2026-45321 (związaną z frameworkiem Mini Shai-Hulud) oraz CVE-2026-48027 (dotyczącą złośliwego kodu w rozszerzeniu Nx Console v18.95.0). Dzień później opublikowano pierwsze samodzielne ostrzeżenie dotyczące kampanii, w którym CISA zaleca pilny przegląd logów CI/CD i rotację wszystkich sekretów dostępnych z potoków budowania.
Co istotne, atrybucja ataków stała się niejednoznaczna. Jak zauważają badacze z Wiz, Microsoft i Unit 42, podobieństwa między nowymi atakami a frameworkiem TeamPCP mogą wynikać zarówno z kontynuacji działań tej grupy, jak i z działalności naśladowców, którzy wykorzystali publicznie udostępniony kod. „Wiz stwierdza, że podobieństwa należy traktować jako dowód na pokrywanie się TTP, a nie jako ostateczną atrybucję do TeamPCP” – czytamy w raporcie SANS.
Dlaczego podpisane atesty nie chronią
Jednym z najbardziej niepokojących wniosków z tej kampanii jest fakt, że podpisane atesty SLSA (Supply-chain Levels for Software Artifacts) nie stanowią skutecznej ochrony. W przypadku ataku na Red Hat, złośliwe pakiety posiadały ważne atesty pochodzenia, ponieważ sam potok budowania został skompromitowany od wewnątrz. Atest potwierdza jedynie, że artefakt pochodzi z danego potoku, ale nie gwarantuje, że potok nie zawierał złośliwych kroków. To kluczowa lekcja dla firm, które ufają wyłącznie mechanizmom weryfikacji pochodzenia.
Dodatkowo, jak wynika z raportu SANS, kanały wymuszeń powiązane z TeamPCP pozostają uśpione – ostatnia aktywność na stronach wycieków datowana jest na kwiecień 2026 roku. Oznacza to, że obecna fala ataków ma charakter „robaka ekosystemowego”, a nie ukierunkowanego wymuszenia. Ofiarami są wszyscy, którzy pobrali skompromitowane pakiety, niezależnie od wielkości firmy.
Jak się bronić – praktyczne kroki
Dla polskich administratorów i programistów najważniejsze są konkretne działania defensywne. Po pierwsze, należy traktować termin 10 czerwca 2026 roku jako wiążący – do tego dnia CISA wymaga usunięcia podatności CVE-2026-45321 i CVE-2026-48027. Należy sprawdzić, czy w środowisku nie ma zainstalowanego rozszerzenia Nx Console w wersji 18.95.0 oraz czy pakiety TanStack są zaktualizowane.
Po drugie, konieczna jest natychmiastowa rotacja wszystkich sekretów dostępnych z potoków CI/CD – tokenów GitHub, kluczy API, haseł do baz danych i poświadczeń chmurowych. Jak pokazał przypadek Grafany, pominięcie choćby jednego tokena może prowadzić do pełnej kompromitacji repozytoriów.
Po trzecie, warto rozszerzyć monitoring na instalacyjne pliki konfiguracyjne, takie jak binding.gyp i node-gyp, ponieważ atakujący celowo omijają standardowe mechanizmy detekcji. W miarę możliwości warto rozważyć uruchamianie instalacji pakietów npm z wyłączonymi skryptami (--ignore-scripts) w środowiskach CI.
Ostatecznie, nie należy polegać wyłącznie na atestach SLSA. Weryfikacja pochodzenia to tylko jeden z elementów bezpieczeństwa – kluczowe jest również monitorowanie integralności potoków budowania i stosowanie zasady najmniejszych uprawnień dla tokenów CI/CD.
Kampania TeamPCP pokazuje, że ataki na łańcuch dostaw ewoluują szybciej niż mechanizmy obronne. Dla polskich firm, które coraz częściej korzystają z open source w krytycznych procesach biznesowych, oznacza to konieczność ciągłego przeglądu zależności i gotowości do szybkiej reakcji. Warto śledzić aktualizacje CISA oraz raporty zespołów CERT, aby być na bieżąco z nowymi zagrożeniami.
