Nowe luki w PHP Composer umożliwiają zdalne wykonanie poleceń w łańcuchu dostaw

securitybeztabu.pl 5 godzin temu

Wprowadzenie do problemu / definicja

W ekosystemie PHP ujawniono dwie istotne podatności w Composerze, czyli podstawowym menedżerze pakietów używanym do instalacji i aktualizacji zależności. Błędy dotyczą obsługi sterownika Perforce VCS i mogą prowadzić do wykonania dowolnych poleceń systemowych w kontekście użytkownika uruchamiającego narzędzie. Problem ma szczególne znaczenie dla bezpieczeństwa łańcucha dostaw oprogramowania, ponieważ atak może zostać osadzony w konfiguracji projektu lub w metadanych repozytorium pakietów.

W skrócie

  • Ujawnione podatności to CVE-2026-40176 oraz CVE-2026-40261.
  • Obie luki wynikają z niewystarczającego oczyszczania danych używanych do budowy poleceń powłoki dla integracji z Perforce.
  • Poprawki opublikowano w wersjach Composer 2.9.6 oraz 2.2.27 LTS.
  • Skuteczne wykorzystanie nie wymaga obecności Perforce na stacji ofiary.
  • Największe ryzyko dotyczy środowisk deweloperskich i pipeline’ów CI/CD.

Kontekst / historia

Composer od lat jest jednym z najważniejszych elementów procesu budowania aplikacji PHP, zarówno w środowiskach developerskich, jak i w automatyzacji CI/CD. Każda podatność umożliwiająca wykonanie poleceń na etapie pobierania, synchronizacji lub aktualizacji kodu może więc wpływać na szeroki fragment procesu wytwarzania oprogramowania.

Obie luki dotyczą sterownika Perforce VCS. Pierwsza z nich, CVE-2026-40176, wiąże się z możliwością wstrzyknięcia komend przez parametry połączenia Perforce, takie jak port, użytkownik czy klient, dostarczone w złośliwym pliku composer.json. Druga, CVE-2026-40261, wynika z niepoprawnego escape’owania referencji źródła oraz powiązanych pól metadanych pakietu. W odpowiedzi na ujawnienie problemu ograniczono publikację metadanych związanych z Perforce w publicznym ekosystemie pakietów, a użytkownikom zalecono natychmiastową aktualizację.

Analiza techniczna

Rdzeń problemu sprowadza się do klasycznego command injection. W podatnych wersjach wartości kontrolowane przez atakującego były osadzane w poleceniach powłoki bez odpowiednich zabezpieczeń. jeżeli dane zawierały znaki specjalne interpretowane przez shell, możliwe było dołączenie dodatkowych komend wykonywanych lokalnie na systemie ofiary.

W przypadku CVE-2026-40176 podatność dotyczy mechanizmu generującego polecenie p4. Atakujący, kontrolując konfigurację repozytorium Perforce w pliku composer.json, mógł doprowadzić do uruchomienia dowolnego polecenia podczas działania Composera. Ten wariant wymaga jednak uruchomienia narzędzia na nieufnym projekcie przygotowanym przez napastnika.

CVE-2026-40261 ma szerszy profil ryzyka. Błąd dotyczy synchronizacji kodu bazowego i pola referencji źródła, które mogło zostać spreparowane z użyciem metaznaków powłoki. W tym scenariuszu złośliwe dane mogą pochodzić z metadanych dostarczanych przez repozytorium pakietów, co zwiększa znaczenie zagrożenia przy instalacji lub aktualizacji zależności ze źródła.

Ważne jest to, iż atak nie wymaga faktycznie zainstalowanego klienta Perforce. Sama próba zbudowania i wykonania polecenia przez Composer może wystarczyć, aby doszło do lokalnego wykonania wstrzykniętych instrukcji. To istotny szczegół z perspektywy obrony, ponieważ część organizacji mogłaby błędnie założyć, iż brak użycia Perforce eliminuje ryzyko.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest zdalne wykonanie poleceń z uprawnieniami użytkownika uruchamiającego Composer. W praktyce może to oznaczać kradzież sekretów z plików środowiskowych, przejęcie tokenów dostępowych do repozytoriów, modyfikację kodu źródłowego, osadzenie backdoora w pipeline’ie lub dalszy ruch boczny w środowisku buildowym.

Ryzyko jest szczególnie wysokie w środowiskach automatyzacji, gdzie Composer działa w systemach CI/CD mających dostęp do kluczy, sekretów wdrożeniowych i infrastruktury produkcyjnej. choćby jeżeli wykonanie kodu następuje tylko w kontekście lokalnego użytkownika, taki kontekst często zapewnia szeroki dostęp do artefaktów, rejestrów kontenerów, systemów podpisywania pakietów czy zasobów chmurowych.

Dodatkowym czynnikiem ryzyka jest charakter supply chain. jeżeli organizacja korzysta z zewnętrznych źródeł pakietów lub importuje projekty z niezweryfikowanych źródeł, prawdopodobieństwo uruchomienia złośliwych metadanych znacząco rośnie. choćby przy braku potwierdzonych incydentów wykorzystania, tego typu luki mają wysoki potencjał operacyjny dla atakujących.

Rekomendacje

Podstawowym działaniem jest natychmiastowa aktualizacja Composera do wersji 2.9.6 albo 2.2.27 LTS, zależnie od używanej gałęzi. Organizacje powinny dodatkowo sprawdzić wszystkie środowiska developerskie, serwery buildowe oraz obrazy kontenerowe zawierające starsze wydania narzędzia.

  • Zablokować użycie nieaktualnych wersji Composera w pipeline’ach CI/CD.
  • Ograniczyć korzystanie z nieufnych lub niestandardowych repozytoriów pakietów.
  • Przeglądać główne pliki composer.json przed uruchomieniem poleceń na projektach pochodzących z zewnętrznych źródeł.
  • Monitorować procesy buildowe pod kątem nietypowych wywołań powłoki i połączeń wychodzących.
  • Separować środowiska budowania od zasobów produkcyjnych oraz minimalizować uprawnienia kont uruchamiających Composer.
  • Przeprowadzić przegląd sekretów dostępnych w jobach CI/CD i rotację tych, które mogły zostać ujawnione.

W organizacjach o wyższym poziomie dojrzałości bezpieczeństwa warto również egzekwować polityki dopuszczonych źródeł pakietów, analizować metadane zależności oraz stosować sandboxing dla procesów budowania. Każde narzędzie działające na etapie pobierania kodu powinno być traktowane jako komponent o wysokim znaczeniu dla bezpieczeństwa łańcucha dostaw.

Podsumowanie

Luki CVE-2026-40176 i CVE-2026-40261 w Composerze pokazują, jak choćby pozornie niszowa integracja z systemem kontroli wersji może stać się realnym wektorem ataku na proces dostarczania oprogramowania. Problem dotyczy niewystarczającego zabezpieczenia danych wejściowych używanych do budowy poleceń powłoki i może prowadzić do wykonania dowolnego kodu lokalnie, także wtedy, gdy Perforce nie jest zainstalowany.

Dla zespołów bezpieczeństwa i DevOps najważniejsze są trzy działania: szybka aktualizacja do wersji naprawionych, ograniczenie zaufania do zewnętrznych projektów i repozytoriów oraz wzmocnienie kontroli bezpieczeństwa w pipeline’ach CI/CD. To kolejny przykład, iż bezpieczeństwo menedżerów pakietów pozostaje jednym z kluczowych elementów ochrony nowoczesnego software supply chain.

Źródła

  1. New PHP Composer Flaws Enable Arbitrary Command Execution — Patches Released — https://thehackernews.com/2026/04/new-php-composer-flaws-enable-arbitrary.html
  2. Composer 2.9.6: Perforce Driver Command Injection Vulnerabilities (CVE-2026-40261, CVE-2026-40176) — https://blog.packagist.com/composer-2-9-6-perforce-driver-command-injection-vulnerabilities/
Idź do oryginalnego materiału