Mini Shai-Hulud: robak w npm i PyPI (2026)

Jesienią 2025 ekosystem npm zobaczył pierwszego samoreplikującego się robaka — Shai-Hulud. W maju 2026 wrócił w nowej odsłonie, ochrzczonej przez badaczy „Mini Shai-Hulud”, i zrobił coś, czego wcześniej nie widziano na taką skalę: zainfekował pakiety w npm i PyPI jednocześnie, w jednej skoordynowanej operacji. Ofiarami padły m.in. popularne biblioteki TanStack oraz komponenty powiązane z Mistral AI i UiPath — łącznie ponad 160 pakietów. To kolejny dowód, że łańcuch dostaw oprogramowania jest dziś jednym z najskuteczniejszych wektorów ataku.

Jak działał atak

Mechanika łączyła przejęcie automatyzacji z klasyczną kradzieżą sekretów, w automatycznej pętli:

1. Wejście przez CI/CD. Według analiz (m.in. Orca Security i Palo Alto Unit 42) punktem zaczepienia był pipeline GitHub Actions projektu TanStack. Napastnicy wykorzystali łańcuch błędów w konfiguracji Actions, by przejąć proces budowania i publikacji.
2. Błyskawiczna publikacja. Po przejęciu pipeline’u złośliwe artefakty zaczęły trafiać do rejestru w tempie automatu — w ciągu kilku minut opublikowano dziesiątki zainfekowanych paczek z rodziny @tanstack/*.
3. Kradzież sekretów. Ładunek przeszukiwał środowisko w poszukiwaniu tokenów npm, poświadczeń chmurowych, kluczy i sekretów pipeline’u, a następnie wyprowadzał je na zewnątrz.
4. Samoreplikacja. Mając wykradzione prawa publikacji, robak automatycznie zatruwał kolejne pakiety utrzymywane przez ofiary — stąd „robak”, a nie pojedynczy złośliwy pakiet.

Dwie cechy wyróżniają tę falę. Po pierwsze, równoczesny atak na npm i PyPI — pierwszy raz w jednej operacji zatruto oba główne rejestry, co pokazuje, że sprawcy myślą już „międzyekosystemowo”. Po drugie, w niektórych wariantach ładunek zawierał destrukcyjny, uporczywy komponent, zdolny kasować katalogi domowe deweloperów — od kradzieży przeszliśmy więc w stronę sabotażu.

Dlaczego to takie groźne

Atak uderza w ten sam fundament, co jego poprzednik: zaufanie do zależności i do automatyzacji. Typowa aplikacja ciągnie setki, pośrednio tysiące pakietów — nikt nie czyta ich kodu przy każdej aktualizacji. Gdy złośliwa wersja wskoczy do buildu, uruchamia się tam, gdzie uprawnienia są najszersze: w CI/CD. A pipeline ma zwykle tokeny do chmury, klucze do wdrożeń i dostęp do rejestrów — czyli potencjalnie klucze do całego środowiska.

Nowość roku 2026 to skala automatyzacji i celowanie w łańcuch narzędziowy dostawcy: przejmuje się nie tyle konto pojedynczego autora, co jego pipeline publikacji. To ta sama rodzina zagrożeń, którą opisywaliśmy przy marcowej fali TeamPCP na CI/CD i szerzej w tekście o atakach na łańcuch dostaw — tu doprowadzona do postaci samoreplikującego się robaka działającego na dwóch rejestrach naraz.

Jak się bronić: praktyczne kroki

Nie zabezpieczysz się przed każdą przyszłą infekcją rejestru, ale możesz drastycznie ograniczyć skutki.

Utwardź GitHub Actions. To był wektor wejścia. Przypinaj akcje do konkretnych sum SHA (nie do ruchomych tagów), ograniczaj domyślne uprawnienia GITHUB_TOKEN do minimum, oddziel workflow publikacji od zwykłego CI i chroń go zatwierdzeniami. Wszędzie, gdzie się da, wydawaj krótkożyjące tokeny przez OIDC zamiast trzymać stałe sekrety.

Przypinaj wersje i używaj lockfile. Instalacja z zablokowanymi wersjami (npm ci zamiast npm install, lockfile w repo; odpowiedniki po stronie Pythona) sprawia, że świeża złośliwa wersja nie wskoczy automatycznie. Rozważ opóźnienie adopcji nowych wydań o kilka dni — wiele złośliwych paczek jest wykrywanych i usuwanych w tym oknie.

Ogranicz skrypty instalacyjne. --ignore-scripts tam, gdzie to możliwe, blokuje najczęstszy wektor wykonania złośliwego kodu podczas instalacji. W CI to szczególnie istotne.

Minimalne uprawnienia w pipeline. Build nie powinien mieć tokenów o szerszym zakresie, niż wymaga konkretne zadanie. Osobne tokeny dla buildu i wdrożenia, bez dostępu do produkcji z etapu instalacji zależności.

Provenance i SBOM. Weryfikacja pochodzenia artefaktów (Sigstore i SLSA) oraz inwentarz zależności pozwalają szybciej odpowiedzieć na pytanie „czy to nas dotyczy” po ogłoszeniu kolejnej fali.

Rotacja sekretów po incydencie. Jeśli mogłeś być w oknie ekspozycji, zakładaj wyciek tokenów i rotuj je. Kradzież sekretów uodparnia na samą „naprawę” pakietu.

Najczęstsze pytania (FAQ)

Używamy npm lub PyPI — czy byliśmy zagrożeni? Potencjalnie tak, jeśli w oknie ataku instalowaliście świeże wersje zainfekowanych pakietów (lub ich zależności) bez zablokowanych wersji, albo z uruchamianiem skryptów w CI. Sprawdź, czy któraś z paczek z listy IOC trafiła do Waszych buildów i czy nie wyciekły tokeny z pipeline’u.

Czym „Mini Shai-Hulud” różni się od oryginału z 2025? Skalą i zasięgiem. Oryginał krążył po npm; wersja z 2026 zaatakowała npm i PyPI jednocześnie, mocniej opierała się na przejęciu pipeline’u publikacji, a w części wariantów dokładała destrukcyjny, kasujący dane komponent.

Jak sprawdzić, czy nasze tokeny nie wyciekły? Przejrzyj logi publikacji w rejestrach i aktywność tokenów GitHub/chmury z okresu ekspozycji, poszukaj nieautoryzowanych publikacji pakietów oraz nietypowego użycia kluczy. W razie wątpliwości — rotuj wszystko, co mogło być w zasięgu ładunku w CI.

Jak przetestować odporność naszego pipeline’u? Audyt bezpieczeństwa obejmujący CI/CD sprawdza zakresy tokenów, konfigurację GitHub Actions, izolację środowisk budowania i ryzyko złośliwych zależności — czyli dokładnie te warunki, które zdecydowały o skali tego robaka.

Podsumowanie

Mini Shai-Hulud potwierdza kierunek, który zapowiadał już oryginał: zautomatyzowane, samoreplikujące się ataki na łańcuch dostaw, rozprzestrzeniające się szybciej, niż zdążysz zareagować ręcznie — a teraz również ponad granicami pojedynczego rejestru. Obrona nie polega na czytaniu kodu każdej zależności, lecz na ograniczaniu skutków: utwardzony pipeline, zablokowane wersje, minimalne uprawnienia i szybka rotacja sekretów. Jeśli tworzysz oprogramowanie, sprawdź swój pipeline, zanim zrobi to kolejny robak.

---

Źródła i dalsza lektura: Orca Security, Palo Alto Unit 42, GitHub Security.