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. Najnowszy incydent związany z ekosystemem Packagist pokazuje, że pojedynczy złośliwy komponent w repozytorium zależności może doprowadzić do wykonania nieautoryzowanego kodu już na etapie instalacji lub budowania projektu.
W analizowanym przypadku zagrożenie dotknęło pakiety wykorzystywane w środowiskach PHP, jednak sam mechanizm infekcji wykorzystywał elementy charakterystyczne dla narzędzi JavaScript. To ważny sygnał ostrzegawczy dla zespołów bezpieczeństwa, które nadal monitorują zależności zbyt wąsko, koncentrując się wyłącznie na jednym ekosystemie.
W skrócie
W maju 2026 roku ujawniono skoordynowaną kampanię supply chain obejmującą osiem pakietów dostępnych w Packagist. Złośliwy kod nie został umieszczony w typowym dla Composera pliku metadanych, lecz w pliku package.json, co mogło pomóc ominąć część standardowych kontroli bezpieczeństwa.
Mechanizm infekcji wykorzystywał skrypt postinstall, który pobierał binarium dla systemu Linux z GitHub Releases, zapisywał je lokalnie, nadawał mu prawa wykonywania i uruchamiał w tle. Choć zainfekowane wersje zostały usunięte, incydent uwidacznia rosnące ryzyko ataków międzyekosystemowych, obejmujących jednocześnie PHP, Node.js oraz pipeline CI/CD.
Kontekst / historia
Packagist jest podstawowym rejestrem pakietów dla Composera i odgrywa kluczową rolę w łańcuchu dostaw aplikacji PHP. Z tego powodu stanowi atrakcyjny cel dla operatorów kampanii ukierunkowanych na deweloperów, systemy automatyzacji budowania oraz środowiska integracji ciągłej.
W opisywanym przypadku zaatakowane zostały pakiety powiązane z różnymi projektami, a złośliwe wersje obejmowały między innymi gałęzie deweloperskie takie jak dev-main, dev-master czy 3.x-dev. Wśród wskazanych komponentów znalazły się pakiety przypisane do różnych autorów i projektów, co sugeruje szerszą oraz bardziej skoordynowaną operację niż pojedyncza kompromitacja jednego repozytorium.
Charakter incydentu wskazuje, że napastnicy starali się doprowadzić do wykonania złośliwego kodu zarówno podczas instalacji zależności, jak i potencjalnie w procesach automatyzacji opartych o workflow buildowe. To szczególnie niebezpieczne, ponieważ środowiska CI/CD często mają dostęp do wrażliwych sekretów, tokenów publikacyjnych i poświadczeń chmurowych.
Analiza techniczna
Najistotniejszym elementem tego incydentu był sposób osadzenia złośliwego kodu. Zamiast wykorzystać composer.json, atakujący umieścili payload w package.json, czyli pliku zwykle kojarzonym z ekosystemem Node.js. Oznacza to, że projekty PHP zawierające dodatkowe narzędzia frontendowe, bundlery lub skrypty buildowe mogły aktywować złośliwy kod mimo pozornie poprawnych metadanych Composera.
Uruchomienie malware opierało się na skrypcie postinstall. Po instalacji pakietu wykonywana była logika pobierająca binarny plik z hostingu release’ów, następnie zapisywano go w katalogu tymczasowym, nadawano mu uprawnienia wykonywania i uruchamiano jako proces działający w tle. Taki schemat działania jasno wskazuje na próbę uzyskania wykonania kodu na hostach deweloperskich, runnerach CI i serwerach budujących bez udziału użytkownika.
Według opisu incydentu malware miało być zapisywane jako /tmp/.sshd. Sama nazwa pliku sugeruje próbę ukrycia aktywności przez nadanie artefaktowi nazwy przypominającej legalny komponent systemowy. Dodatkowo wskazywano na techniki takie jak tłumienie błędów, osłabianie weryfikacji połączeń oraz uruchamianie procesu w tle, co ogranicza widoczność zdarzenia w logach i utrudnia szybką diagnozę.
Badacze zwrócili także uwagę, że podobny payload pojawiał się w wielu plikach hostowanych w serwisie GitHub, co może sugerować szerszą kampanię obejmującą więcej niż jeden ekosystem i więcej niż jedną metodę uruchomienia. W części przypadków złośliwe odwołania miały zostać dodane również do workflow automatyzacji, co dodatkowo zwiększa ryzyko dla środowisk CI/CD.
Konsekwencje / ryzyko
Ryzyko związane z tym incydentem należy ocenić jako wysokie, ponieważ atak dotyczył etapu zaufanej instalacji zależności. Jeśli organizacja pobrała zainfekowaną wersję pakietu, skutkiem mogło być zdalne wykonanie kodu na stacji roboczej dewelopera, w kontenerze budującym lub na serwerze automatyzacji.
W praktyce otwiera to drogę do kradzieży sekretów, tokenów CI/CD, kluczy API, poświadczeń chmurowych oraz modyfikacji artefaktów budowania. Jeszcze poważniejsze staje się to w środowiskach, w których runner posiada uprawnienia do publikowania pakietów, podpisywania artefaktów, wdrażania aplikacji lub modyfikowania repozytoriów kodu.
Drugim poziomem zagrożenia jest możliwość dalszego przemieszczania się napastnika w infrastrukturze deweloperskiej. Kompromitacja jednego runnera lub hosta buildowego może stać się punktem wejścia do trwałych zmian w workflow, zależnościach lub procesie wydawniczym. Oznacza to, że skutki incydentu mogą wykraczać poza pojedynczy serwer i objąć cały cykl dostarczania oprogramowania.
Istotnym problemem pozostaje również błędna ocena ekspozycji. Organizacje monitorujące wyłącznie composer.json i standardowe zależności PHP mogły nie zauważyć zagrożenia, ponieważ rzeczywisty wektor wykonania znajdował się w pliku kojarzonym z innym ekosystemem. To pokazuje, że nowoczesna analiza SBOM i bezpieczeństwa zależności musi obejmować wszystkie warstwy projektu.
Rekomendacje
Organizacje korzystające z Packagist i Composera powinny niezwłocznie przeprowadzić przegląd używanych pakietów, ze szczególnym uwzględnieniem wersji deweloperskich takich jak dev-main i dev-master. Należy ustalić, czy wskazane komponenty były pobierane, instalowane lub budowane w środowiskach lokalnych, testowych i produkcyjnych.
Konieczne jest rozszerzenie kontroli bezpieczeństwa na pliki package.json, skrypty lifecycle oraz workflow CI/CD. Skanowanie zależności nie powinno ograniczać się do composer.json i composer.lock, lecz obejmować także elementy JavaScript obecne w projektach PHP.
- przeprowadzić przegląd logów instalacji pakietów i pipeline’ów buildowych,
- sprawdzić, czy w środowiskach nie pojawił się plik
/tmp/.sshdlub podobne artefakty, - dokonać rotacji sekretów dostępnych dla stacji deweloperskich i runnerów CI,
- zweryfikować tokeny GitHub, klucze wdrożeniowe i poświadczenia chmurowe,
- ograniczyć uruchamianie skryptów instalacyjnych podczas pobierania zależności,
- blokować nieautoryzowane połączenia wychodzące do nieznanych repozytoriów i hostingu release’ów,
- preferować przypięte wersje pakietów oraz zaufane mirrory,
- wdrożyć polityki allowlist i izolację runnerów CI.
Dodatkowo warto rozważyć zastosowanie narzędzi klasy dependency firewall, systemów reputacyjnych dla pakietów open source oraz obowiązkowej recenzji zmian w plikach konfiguracyjnych buildów. W środowiskach o wyższych wymaganiach bezpieczeństwa dobrym rozwiązaniem jest uruchamianie instalacji zależności w piaskownicach z ograniczonym dostępem do sieci i sekretów.
Podsumowanie
Incydent w Packagist jest kolejnym dowodem na to, że ataki na łańcuch dostaw stają się coraz bardziej złożone i coraz częściej przekraczają granice pojedynczych ekosystemów technologicznych. W tym przypadku złośliwy kod ukryto poza standardowym miejscem, którego zwykle oczekują zespoły bezpieczeństwa analizujące projekty PHP.
Efektem było uruchamianie binariów Linuksa podczas instalacji pakietów, co mogło prowadzić do kompromitacji środowisk developerskich i CI/CD. Najważniejszy wniosek operacyjny jest prosty: bezpieczeństwo zależności należy analizować holistycznie, obejmując metadane, skrypty lifecycle, workflow automatyzacji oraz wszystkie komponenty projektów wieloekosystemowych.
Źródła
- https://thehackernews.com/2026/05/packagist-supply-chain-attack-infects-8.html
- https://socket.dev
- https://docs.github.com/actions
- https://packagist.org