Krytyczne luki w PHP Composerze: Perforce VCS otwiera drogę do zdalnego wykonania poleceń

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

W ekosystemie PHP wykryto dwie krytyczne podatności w Composerze, najpopularniejszym menedżerze zależności dla tego języka. Luki dotyczą obsługi sterownika Perforce VCS i mogą prowadzić do wstrzyknięcia poleceń systemowych, a w konsekwencji do zdalnego wykonania komend na urządzeniu ofiary.

Problem jest szczególnie groźny, ponieważ Composer stanowi podstawowy element procesu budowania aplikacji, zarówno na stacjach deweloperskich, jak i w środowiskach CI/CD. Oznacza to, że skutki potencjalnego ataku mogą wykraczać daleko poza pojedynczy projekt.

W skrócie

Podatności oznaczono jako CVE-2026-40176 oraz CVE-2026-40261.
Obie luki dotyczą integracji Composera z Perforce VCS.
Źródłem problemu jest niewystarczająca walidacja i niepoprawne escapowanie danych wejściowych.
Atak może zostać przeprowadzony przez złośliwy plik composer.json lub spreparowane metadane repozytorium.
Poprawki opublikowano w wersjach Composer 2.9.6 oraz 2.2.27 LTS.
Dodatkowo wyłączono publikację metadanych Perforce jako środek zapobiegawczy.

Kontekst / historia

Composer od lat pozostaje jednym z najważniejszych narzędzi w łańcuchu dostaw oprogramowania dla PHP. Odpowiada za pobieranie, rozwiązywanie oraz aktualizowanie zależności, dlatego każda luka w jego działaniu ma bezpośredni wpływ na bezpieczeństwo procesów developerskich i wdrożeniowych.

W tym przypadku problem dotyczy Perforce, systemu kontroli wersji wykorzystywanego przede wszystkim w środowiskach korporacyjnych oraz tam, gdzie stosowany jest scentralizowany model zarządzania kodem. Ujawnione podatności wpisują się w szerszy trend ataków na narzędzia software supply chain, w których celem nie jest sam pakiet, lecz mechanizm pobierania i przetwarzania danych źródłowych.

To ważna zmiana perspektywy: zagrożenie nie wynika wyłącznie z instalacji złośliwej biblioteki, ale także z manipulacji konfiguracją repozytorium i danymi używanymi przez zaufane narzędzie buildowe.

Analiza techniczna

Podatność CVE-2026-40176 dotyczy scenariusza, w którym atakujący przygotowuje złośliwy projekt zawierający odpowiednio spreparowaną konfigurację repozytorium Perforce w pliku composer.json. Parametry takie jak port, użytkownik czy klient mogły zostać użyte podczas budowania poleceń systemowych bez właściwej sanitizacji.

W efekcie uruchomienie Composera na takim projekcie mogło doprowadzić do wykonania arbitralnych komend w kontekście użytkownika, który inicjuje instalację lub aktualizację zależności. To oznacza możliwość nadużycia zarówno na stacji roboczej programisty, jak i na serwerze automatyzującym proces budowania.

CVE-2026-40261 oceniana jest jako jeszcze poważniejsza, ponieważ umożliwia wstrzyknięcie poleceń przez spreparowaną referencję źródłową zawierającą metaznaki powłoki. Problem wynika z nieprawidłowego escapowania danych wykorzystywanych podczas synchronizacji kodu z repozytorium.

Istotne jest także to, że ryzyko może wystąpić nawet wtedy, gdy Perforce nie jest lokalnie zainstalowany. Wystarczy, że Composer przetworzy odpowiednio przygotowane metadane podczas operacji związanych z pobieraniem zależności ze źródła.

Z technicznego punktu widzenia obie luki sprowadzają się do klasycznego błędu typu command injection. Dane pochodzące z zewnętrznego źródła trafiają do poleceń powłoki bez wystarczającego ograniczenia znaków specjalnych i bez bezpiecznego rozdzielenia argumentów. W narzędziach developerskich taki błąd jest wyjątkowo niebezpieczny, ponieważ często mają one dostęp do kodu, kluczy SSH, tokenów oraz sekretów wykorzystywanych w pipeline’ach.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest możliwość zdalnego wykonania poleceń na systemie ofiary. Taki scenariusz może prowadzić do instalacji tylnej furtki, przejęcia danych uwierzytelniających, kradzieży sekretów, modyfikacji artefaktów budowania oraz dalszego przemieszczania się napastnika po infrastrukturze organizacji.

Szczególnie narażone są środowiska CI/CD, gdzie Composer bywa uruchamiany automatycznie i często działa z szerokimi uprawnieniami. W przypadku błędnej segmentacji infrastruktury atak może objąć nie tylko runner buildowy, ale również wewnętrzne repozytoria, systemy wdrożeniowe czy zasoby produkcyjne.

Ryzyko jest dodatkowo podwyższone przez fakt, że narzędzia buildowe są zazwyczaj traktowane jako element zaufany. To właśnie ten poziom uprzywilejowania sprawia, że luki w komponentach supply chain mają tak duży potencjał operacyjny dla atakujących.

Rekomendacje

Najważniejszym krokiem jest niezwłoczna aktualizacja Composera do wersji 2.9.6 lub 2.2.27 LTS, zależnie od używanej gałęzi. Organizacje powinny sprawdzić nie tylko komputery deweloperskie, lecz także obrazy kontenerowe, runner’y CI, hosty administracyjne oraz wszystkie miejsca, w których Composer może być uruchamiany pośrednio.

Warto także ograniczyć instalację zależności bezpośrednio ze źródła i preferować tryb dist, jeśli pozwala na to proces wytwórczy. Zmniejsza to powierzchnię ataku związaną z przetwarzaniem metadanych repozytoriów VCS.

uruchamiać Composera wyłącznie na zaufanych projektach,
przeprowadzić audyt plików composer.json pod kątem niestandardowych definicji repozytoriów Perforce,
ograniczyć uprawnienia runnerów CI/CD i odseparować je od krytycznych zasobów,
przeprowadzić rotację sekretów, jeśli podatne wersje były używane w niezaufanych projektach,
monitorować logi buildów pod kątem anomalii i nieoczekiwanego wykonywania poleceń.

Dobrą praktyką pozostaje również zasada minimalnych uprawnień. Narzędzia budujące nie powinny mieć domyślnego dostępu do pełnego zestawu sekretów organizacji, ponieważ ograniczenie uprawnień może znacząco zmniejszyć skalę potencjalnego incydentu.

Podsumowanie

Luki CVE-2026-40176 i CVE-2026-40261 pokazują, że bezpieczeństwo narzędzi developerskich ma bezpośredni wpływ na integralność całego łańcucha dostaw oprogramowania. W tym przypadku problem w obsłudze Perforce VCS przez Composer może doprowadzić do wykonania dowolnych poleceń poprzez manipulację konfiguracją projektu lub metadanymi repozytorium.

Dla organizacji korzystających z PHP oznacza to konieczność pilnej aktualizacji oraz przeglądu sposobu, w jaki zależności są pobierane i przetwarzane w środowiskach developerskich i CI/CD. Zaufanie do zewnętrznych danych wejściowych w procesie buildowym powinno być minimalizowane, a mechanizmy bezpieczeństwa wokół tych procesów regularnie weryfikowane.