Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających i utrzymujących aplikacje. Najnowsza kampania Shai-Hulud pokazuje, że cyberprzestępcy coraz skuteczniej wykorzystują zaufanie do publicznych repozytoriów pakietów, takich jak NPM i PyPI, aby wprowadzać złośliwy kod do środowisk deweloperskich, procesów CI/CD oraz systemów produkcyjnych.
W opisywanej fali ataków zainfekowano ponad 100 pakietów, a malware nie ograniczał się wyłącznie do jednorazowej infekcji. Jego celem była kradzież poświadczeń, tokenów i kluczy API, a następnie wykorzystanie ich do dalszego rozprzestrzeniania się w kolejnych projektach i zależnościach.
W skrócie
- Nowe warianty Shai-Hulud, nazwane Miasma i Hades, objęły ponad 100 pakietów w NPM i PyPI.
- Kampania nasiliła się na początku czerwca 2026 roku.
- Złośliwy kod uruchamiał się podczas instalacji pakietu lub startu interpretera Python.
- Malware wyszukiwał sekrety, tokeny i dane dostępowe do usług chmurowych oraz systemów publikacji pakietów.
- Przejęte poświadczenia były wykorzystywane do kompromitacji kolejnych pakietów i dalszego szerzenia infekcji.
Kontekst / historia
Shai-Hulud nie jest całkowicie nowym zagrożeniem, lecz rozwinięciem wcześniejszych kampanii wymierzonych w ekosystem open source. Według dostępnych analiz aktywność związana z tym mechanizmem była obserwowana już od września 2025 roku. Istotnym momentem w rozwoju zagrożenia miało być upublicznienie kodu źródłowego robaka w maju 2026 roku, co mogło przyspieszyć pojawienie się nowych klonów oraz wariantów.
Na początku czerwca 2026 roku aktywność operatorów wyraźnie wzrosła. Najpierw raportowano incydenty dotyczące pakietów JavaScript, a następnie podobny model działania został zauważony również w PyPI. To potwierdziło, że kampania nie jest ograniczona do jednego języka czy jednego repozytorium, lecz stanowi wieloplatformowy atak na proces dostarczania oprogramowania.
Analiza techniczna
Wariant Miasma był powiązany przede wszystkim z pakietami NPM. W praktyce pełnił rolę wieloetapowego droppera uruchamianego podczas instalacji zależności. W części przypadków wykorzystywano zmodyfikowane pliki budowania, w tym binding.gyp, aby ominąć prostsze metody wykrywania skoncentrowane na standardowych skryptach instalacyjnych. Taka technika utrudnia identyfikację zagrożenia podczas rutynowej analizy manifestu pakietu.
Po wykonaniu malware przeszukiwał środowisko lokalne i powiązane usługi w poszukiwaniu sekretów. Celem były przede wszystkim tokeny publikacyjne, klucze API, dane CI/CD, poświadczenia do rejestrów pakietów oraz inne informacje umożliwiające publikowanie lub modyfikowanie komponentów. To właśnie zdolność do wykorzystania skradzionych danych do infekowania kolejnych pakietów sprawia, że Shai-Hulud ma charakter samopowielającego się zagrożenia łańcucha dostaw.
Wariant Hades został zidentyfikowany w PyPI i wykorzystywał mechanizm wykonywania kodu przy starcie środowiska Python za pomocą plików *.pth. Taki plik może zostać przetworzony przez interpreter podczas inicjalizacji, co umożliwia uruchomienie dodatkowego kodu bez bezpośredniej akcji użytkownika. W analizowanej kampanii rozwiązanie to służyło między innymi do pobrania runtime’u Bun oraz uruchomienia dalszych komponentów napisanych w JavaScript.
Badacze wskazali także na zmiany w łańcuchu wykonania złośliwego kodu. W nowszych próbkach payload nie zawsze był osadzony bezpośrednio w loaderze. Zamiast tego operatorzy rozdzielali funkcje odpowiedzialne za inicjalizację i właściwe wykonanie, a także wykorzystywali mechanizmy przeszukiwania ścieżek środowiska, aby utrudnić wykrycie. To sugeruje aktywny rozwój kampanii i szybkie dostosowywanie technik do publikowanych analiz oraz mechanizmów obronnych.
Konsekwencje / ryzyko
Ryzyko związane z tą kampanią jest wysokie, ponieważ zainfekowane pakiety mogą zostać pobrane automatycznie przez pipeline’y budowania, stacje robocze programistów i środowiska produkcyjne. Jeżeli malware uzyska dostęp do sekretów, może doprowadzić do wtórnych naruszeń obejmujących repozytoria kodu, rejestry pakietów, systemy CI/CD oraz infrastrukturę chmurową.
Szczególnie narażone są organizacje, które:
- publikują własne pakiety do NPM lub PyPI,
- przechowują tokeny wydawnicze w zmiennych środowiskowych,
- nie stosują krótkowiecznych poświadczeń,
- nie monitorują zmian w zależnościach i lockfile’ach,
- pozwalają na automatyczne wykonywanie skryptów instalacyjnych bez dodatkowej kontroli.
Skutki incydentu mogą obejmować kompromitację kont maintainerów, nieautoryzowane publikacje nowych wersji, przejęcie procesów build i release, wyciek danych projektowych oraz dalsze rozprzestrzenienie zagrożenia na klientów i partnerów. W środowiskach przedsiębiorstw oznacza to również koszty operacyjne, obowiązki związane z reakcją na incydent oraz ryzyko utraty zaufania.
Rekomendacje
Organizacje korzystające z NPM i PyPI powinny traktować tego typu zdarzenie jako pełnoskalowy incydent supply chain. W pierwszej kolejności warto ustalić, czy w środowisku występowały zainfekowane wersje pakietów, a następnie przeprowadzić rotację wszystkich potencjalnie zagrożonych sekretów.
- Zweryfikować historię pobrań i buildów pod kątem złośliwych pakietów.
- Przeprowadzić rotację tokenów NPM, PyPI, GitHub oraz poświadczeń CI/CD.
- Sprawdzić historię publikacji własnych pakietów i wykryć ewentualne nieautoryzowane wersje.
- Ograniczyć automatyczne wykonywanie skryptów instalacyjnych tam, gdzie jest to możliwe.
- Monitorować pliki i mechanizmy takie jak
postinstall,binding.gyp,setup.py,pyproject.tomloraz*.pth. - Wdrożyć zasadę najmniejszych uprawnień dla tokenów publikacyjnych i odejść od statycznych sekretów na rzecz krótkowiecznych poświadczeń.
- Rozszerzyć detekcję o analizę zachowań pakietów, a nie tylko sygnatury.
- Stosować SBOM, podpisywanie artefaktów i kontrolę provenance buildów.
Ważnym elementem obrony jest również zabezpieczenie kont maintainerów z użyciem MFA oraz ścisła segmentacja uprawnień publikacyjnych. W praktyce to właśnie ograniczenie dostępu i szybka rotacja sekretów mogą znacząco zmniejszyć skalę wtórnych naruszeń.
Podsumowanie
Kampania Shai-Hulud potwierdza, że ataki na łańcuch dostaw open source stają się coraz bardziej zautomatyzowane, skalowalne i trudniejsze do wykrycia. Warianty Miasma i Hades wykorzystują odmienne techniki wykonania kodu w ekosystemach NPM i PyPI, ale ich cel pozostaje wspólny: kradzież poświadczeń i dalsze infekowanie zależności.
Dla organizacji oznacza to konieczność traktowania bezpieczeństwa pakietów jako integralnej części ochrony środowisk deweloperskich i procesów wydawniczych. Kluczowe znaczenie mają szybkie wykrycie kompromitacji, kontrola nad zależnościami oraz konsekwentne ograniczanie zaufania do zewnętrznych komponentów.
Źródła
- SecurityWeek — Over 100 NPM, PyPI Packages Hit in New Shai-Hulud Supply Chain Attacks — https://www.securityweek.com/over-100-npm-pypi-packages-hit-in-new-shai-hulud-supply-chain-attacks/
- Socket — analiza wariantu Hades i złośliwych pakietów PyPI — https://socket.dev/
- StepSecurity — raporty dotyczące kampanii Shai-Hulud w ekosystemach NPM i PyPI — https://www.stepsecurity.io/
- Snyk — analiza złośliwych pakietów powiązanych z wariantem Miasma — https://snyk.io/
- Endor Labs — analiza aktywności w PyPI i zjawiska phantom releases — https://www.endorlabs.com/