Atak Shai-Hulud na PyPI: 19 pakietów naukowych złośliwie zmodyfikowanych w kampanii supply chain

Wprowadzenie do problemu / definicja

Ekosystem PyPI jest jednym z najważniejszych elementów łańcucha dostaw oprogramowania dla projektów tworzonych w Pythonie. Każde naruszenie integralności pakietów publikowanych w tym rejestrze może prowadzić do przejęcia środowisk deweloperskich, wycieku sekretów oraz dalszego rozprzestrzeniania złośliwego kodu w pipeline’ach CI/CD. Najnowsza kampania przypisywana rodzinie Shai-Hulud pokazuje, że atakujący coraz skuteczniej wykorzystują zaufanie do bibliotek open source, szczególnie tych używanych w obszarze nauki i bioinformatyki.

W skrócie

W czerwcu 2026 roku ujawniono kampanię supply chain wymierzoną w 19 pakietów PyPI powiązanych głównie z zastosowaniami naukowymi i bioinformatycznymi. Łącznie zidentyfikowano 37 złośliwych wydań, które wykorzystywały pliki .pth do uruchamiania kodu już przy starcie interpretera Pythona, bez konieczności bezpośredniego importowania zainfekowanego modułu.

Łańcuch infekcji prowadził do pobrania środowiska Bun i uruchomienia ukrytego ładunku JavaScript odpowiedzialnego za kradzież tokenów, kluczy, danych chmurowych oraz innych sekretów deweloperskich. Celem kampanii było przejęcie stacji roboczych programistów oraz workflowów automatyzacji.

Kontekst / historia

Shai-Hulud to nazwa szerszej serii kampanii wymierzonych w łańcuch dostaw oprogramowania, obserwowanych wcześniej również w ekosystemach npm i PyPI. Wspólnym elementem tych operacji jest przejmowanie lub zatruwanie pakietów, a następnie wykorzystywanie ich do pozyskania sekretów z maszyn deweloperskich i środowisk CI/CD.

W najnowszej odsłonie ataku szczególną uwagę zwraca dobór celów. Zamiast powszechnie rozpoznawalnych bibliotek ogólnego zastosowania, zaatakowano pakiety używane w analizie obrazów, bioinformatyce, badaniach naukowych i narzędziach dla data science. Taki wybór sugeruje próbę dotarcia do organizacji akademickich, laboratoriów, zespołów badawczo-rozwojowych oraz środowisk korzystających ze współdzielonych zasobów obliczeniowych.

Analiza techniczna

Kluczowym elementem technicznym kampanii było wykorzystanie plików .pth umieszczanych w pakietach. Mechanizm ten jest szczególnie niebezpieczny, ponieważ Python może przetwarzać wykonywalne linie z takich plików podczas uruchamiania interpretera. W praktyce oznacza to, że sama obecność złośliwego pakietu w środowisku może wystarczyć do aktywacji kodu przy kolejnym uruchomieniu python, pip, testów, notebooka Jupyter lub zadania CI.

W opisywanej kampanii plik startowy inicjował pobranie środowiska Bun, a następnie uruchamiał zaciemniony ładunek JavaScript o nazwie _index.js. To nietypowe, ale skuteczne podejście: Python pełnił rolę punktu wejścia, natomiast właściwa logika kradzieży danych i dalszych działań była realizowana w JavaScript. Taki model zwiększa przenośność malware’u i może utrudniać analizę, zwłaszcza gdy monitoring skupia się wyłącznie na samych pakietach Python.

Z analizy wynika, że złośliwe oprogramowanie było ukierunkowane na szeroki zestaw sekretów i danych dostępowych.

• tokeny GitHub i sekrety GitHub Actions,
• dane dostępowe do npm, PyPI, RubyGems i innych systemów publikacyjnych,
• poświadczenia AWS, GCP, Azure, Kubernetes i Vault,
• klucze SSH,
• dane logowania Dockera,
• pliki .env, .npmrc, .pypirc,
• historię poleceń powłoki,
• pliki konfiguracyjne związane z narzędziami AI i MCP.

Mechanizmy eksfiltracji także wskazują na dojrzałość operacji. Jedna z metod miała polegać na tworzeniu repozytoriów i zapisywaniu danych z użyciem mechanizmów automatyzacji, co utrudnia odróżnienie aktywności atakującego od legalnych działań deweloperskich. Zaobserwowano również alternatywną ścieżkę eksfiltracji przez HTTPS, przypominającą ruch do legalnego API. Malware zawierał ponadto elementy unikania detekcji, w tym sprawdzanie ustawień regionalnych i obecności narzędzi bezpieczeństwa.

W zakresie utrwalania obecności operatorzy stosowali techniki zależne od systemu operacyjnego. Na Linuksie wskazywano na wykorzystanie usług systemd, a na macOS na mechanizmy LaunchAgents. Dodatkowo modyfikowane mogły być pliki workflowów i konfiguracje wykorzystywane w procesach developerskich, co zwiększało szansę na długotrwałe utrzymanie dostępu.

Konsekwencje / ryzyko

Ryzyko związane z incydentem jest wysokie, ponieważ skutki wykraczają daleko poza pojedynczą stację roboczą. Przejęcie tokenów publikacyjnych i sekretów CI/CD może prowadzić do dalszej kompromitacji całego łańcucha dostaw oprogramowania.

• przejęcie kont wydawców pakietów,
• publikacja kolejnych złośliwych wersji oprogramowania,
• modyfikacja workflowów budowania i wdrażania,
• dostęp do repozytoriów prywatnych,
• wyciek danych badawczych lub własności intelektualnej,
• dalsza kompromitacja infrastruktury chmurowej.

Szczególnie narażone są organizacje, które automatycznie aktualizują zależności, korzystają ze wspólnych obrazów kontenerowych lub uruchamiają zadania w notebookach i klastrach badawczych. Opóźnione wykonanie kodu przez pliki .pth jest trudniejsze do wykrycia niż klasyczne instrukcje uruchamiane podczas instalacji pakietu, co zwiększa prawdopodobieństwo pozostania infekcji niezauważoną do czasu eksfiltracji sekretów.

Z perspektywy bezpieczeństwa łańcucha dostaw szczególnie groźny jest fakt, że atak nie wymaga aktywnego użycia zainfekowanej biblioteki. Wystarczy, że pakiet znajdzie się w środowisku i interpreter Python zostanie uruchomiony w dowolnym kontekście.

Rekomendacje

Organizacje, które mogły zainstalować zagrożone pakiety lub wskazane wersje, powinny potraktować incydent jako potencjalne naruszenie poświadczeń i integralności środowiska.

• Przeprowadzić natychmiastową inwentaryzację hostów, kontenerów, środowisk wirtualnych i pipeline’ów CI/CD pod kątem obecności zagrożonych pakietów.
• Założyć kompromitację sekretów i przeprowadzić rotację tokenów GitHub, poświadczeń chmurowych, kluczy SSH oraz danych publikacyjnych.
• W przypadku potwierdzonej ekspozycji odtworzyć środowiska z zaufanych backupów lub czystych obrazów bazowych.
• Monitorować katalogi site-packages pod kątem podejrzanych plików .pth i wykonywalnych wpisów startowych.
• Wdrożyć detekcję nietypowych łańcuchów procesów, takich jak uruchamianie Bun przez proces Python.
• Ograniczyć automatyczne aktualizacje bez walidacji, stosować pinning wersji i weryfikację artefaktów.
• Segmentować środowiska budowania i stosować zasadę najmniejszych uprawnień.
• Uruchomić formalne procedury zgłoszeniowe do operatorów rejestrów i wewnętrznych zespołów bezpieczeństwa.

Podsumowanie

Incydent Shai-Hulud na PyPI potwierdza, że ataki supply chain coraz częściej wykorzystują mniej oczywiste mechanizmy wykonywania kodu, takie jak pliki .pth, aktywujące się przy uruchomieniu interpretera. Takie podejście może omijać część tradycyjnych metod detekcji skoncentrowanych na etapie instalacji lub imporcie modułu.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona łańcucha dostaw nie może ograniczać się wyłącznie do skanowania zależności pod kątem znanych podatności. Niezbędne jest monitorowanie zachowań pakietów po instalacji, kontrola artefaktów startowych środowiska Python oraz szybka rotacja poświadczeń po każdym incydencie dotyczącym repozytoriów pakietów.

Źródła

1. BleepingComputer — New Shai-Hulud attack trojanizes 19 science-focused PyPI packages — https://www.bleepingcomputer.com/news/security/new-shai-hulud-attack-trojanizes-19-science-focused-pypi-packages/
2. Python Documentation — site — Site-specific configuration hook — https://docs.python.org/3/library/site.html
3. PyPI Blog — Malware Reporting Evolved — https://blog.pypi.org/posts/2024-03-06-malware-reporting-evolved/
4. Elastic Security — Python Path File (pth) Creation — https://www.elastic.co/guide/en/security/current/python-path-file-pth-creation.html
5. Dark Reading — ‘Hades’ Attacks on PyPI Put New Spin on Shai-Hulud — https://www.darkreading.com/application-security/hades-campaign-pypi-shai-hulud