Temat niedawnych podatności w języku PHP stał się niemal tzw. viralem i z pewnością zdecydowana większość osób jakkolwiek związanych z branżą IT zdążyła już zapoznać się ze szczegółami. Sprawę wciąż można określić jako rozwojową, dlatego też postanowiliśmy nieco poczekać z przygotowaniem artykułu, aby w miarę możliwości przedstawić najwięcej istotnych i potwierdzonych faktów.
Wszystko zaczęło się w nocy 20 października, gdy zespół odpowiedzialny za rozwój języka PHP opublikował informację o planowanym wydaniu poprawek bezpieczeństwa dla dwóch krytycznych podatności. Prawdziwa dyskusja pojawiła się pod wpisem zamieszczonym w serwisie X przez The PHP Foundation.
The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2.
PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence.
— The PHP Foundation (@ThePHPF) October 20, 2026
Komentujący zaczęli oznaczać profile Cloudflare, dostawców hostingu i autorów systemów zarządzania treścią. Można było odnieść wrażenie, iż wszyscy oczekiwali na wydanie aktualizacji, a także zastanawiali się, czy niewspierane wersje otrzymają poprawki błędów.
W międzyczasie użytkownik J4ck3LSyN zdążył przygotować PoC, czyli narzędzie stanowiące „dowód”, iż daną podatność można realnie wykorzystać. W tym przypadku oczywiście była to podatność RCE, co oznacza, iż atakujący mógł otrzymać dostęp do powłoki systemu operacyjnego na prawach użytkownika wykonującego skrypty PHP. Szerokie omówienie tematu działania PHP i praw użytkowników wymagałoby osobnego artykułu, bo w popularnej „skondensowanej formie” naprawdę trudno byłoby przedstawić wszystkie aspekty z tym związane – niemniej jest to bardzo interesujące i zdecydowanie polecam zapoznać się z praktyczną stroną konfiguracji serwerów HTTP i PHP.
Dalsze kroki tak naprawdę są zależne od umiejętności i faktycznych celów atakującego – może wykraść dostępy do innych usług zapisane w plikach konfiguracyjnych, skompromitować nasze serwisy podmianą treści czy wreszcie pozostawać w ukryciu (dodając swoje „punkty wejścia” działające po usunięciu podatności) i czekać na odpowiedni w swojej ocenie moment. Dla aplikacji PHP charakterystyczne jest przechowywanie konfiguracji w plikach bądź zmiennych środowiskowych dostępnych z poziomu serwera, przez co ich odczyt jest ułatwiony.
Pojawiły się wpisy wulgarnie określające autora, bo udostępniając dość ograniczone (działające na konkretnym stacku technologicznym) rozwiązanie pozwolił innym na dostosowanie go do własnych exploitów. Jest to częściowa prawda, ponieważ nie on jeden rozpoczął analizę kodu PHP celem odnalezienia źródła wymienionych podatności, a dodatkowo uruchomienie prawdziwego ataku wymaga więcej przygotowań niż tylko wykonanie skryptu z podaniem adresu URL jako parametru.
W serwisie GitHub regularnie zaczęły pojawić się repozytoria zawierające rzekome exploity. Sporo z nich to wiadomy „AI slop”, natomiast nie można wykluczyć, iż znajdą się też w pełni działające narzędzia. Z drugiej strony wiadomo już, iż te podatności są bardzo zależne od konfiguracji interpretera PHP zastosowanych na serwerze, a także od wersji samych binarek php (zresztą większość udostępnionych PoC zawiera też pliki docker-compose.yml pozwalające przygotować lokalne środowisko dedykowane dla konkretnego narzędzia). W związku z tym bardzo mało prawdopodobne jest, iż powstanie exploit działający na każdym systemie, ale nie oznacza to, iż można pozostać biernym i zwlekać z aktualizacją PHP – aczkolwiek i od tego są wyjątki.
Podkreślić trzeba jednak, iż użycie podatności przeciwko środowisku, nad którym atakujący nie ma kontroli, jest trudne.
Do czasu opublikowania poprawek częściową mitygację (zabezpieczenie przed użyciem podatności) stanowiło zablokowanie funkcji session.upload_progress.enabled. Jednak dopiero aktualizacja zapewnia całkowitą ochronę przed tymi konkretnymi podatnościami CVE-2026-109618 i CVE-2026-109619. W sieci pojawiają się sygnały, iż w pewnych warunkach wciąż możliwy jest atak, natomiast z powodu braku jednoznacznych dowodów (choćby działający PoC) na ten moment można poddać to w wątpliwość.
W całej historii z opisywanymi podatnościami znajdziemy kilka wartych uwagi wątków.
Zaraz po opublikowaniu aktualizacji rozpoczęto prace nad ich wdrożeniem, a niektórzy dostawcy usług wcześniej samodzielnie zadbali o ograniczenie możliwości ataku. Sama aktualizacja pakietów związanych z PHP z reguły nie sprawia trudności – chyba iż administratorzy zastosowali pewne niestandardowe konfiguracje serwera.
W przypadku tej podatności klienci wybranego hostingu nie mieli w zasadzie żadnej sprawczości, aby we własnym zakresie zaadresować mitygację. Należało oczekiwać więc, iż to dostawcy usług hostingowych zajmą się problemem po swojej stronie. Nie oszukujmy się też, iż pomimo rozpoznawalności opisywanych podatności osoby spoza branży czy te całkowicie nie zainteresowane kwestiami swoich stron internetowych mogły zwyczajnie nie wiedzieć, iż sytuacja jest dość poważna.
Oficjalne aktualizacje rzecz jasna obejmowały wyłącznie wersje wspierane, czyli od 8.2. jeżeli zainstalowane były wersje starsze, co nie jest zaskoczeniem w przypadku usług hostingowych, to należało liczyć na udostępnienie backportów, czyli poprawek przygotowanych na przykład przez producenta systemu operacyjnego bądź też zamieszczonych w prywatnych repozytoriach pakietów.
Niektórzy dostawcy (tacy jak cyber_Folks, ale lista przykładów jest dłuższa) na podstawie analizy zmian wprowadzonych przez zespół utrzymujący PHP przygotowali własne poprawki dla starszych wersji tego interpretera.
O ile utrzymywanie samodzielnie skompilowanych pakietów PHP jest zasadne (pełna możliwość kontroli nad zmianami przy jakichkolwiek aktualizacjach), to jednak tym razem nie było konieczności manualnego wprowadzania zmian w kodzie. Wersje backport z poprawkami bezpieczeństwa zostały udostępnione m.in. w repozytorium sury.org czy remirepo.net. Odpowiednio w systemach opartych na dystrybucji Debian i RHEL są to standardowe źródła instalacji modułów PHP, więc wdrożenie aktualizacji nie było skomplikowane.
Teraz już jest jasna wspomniana zależność od wersji PHP i ustawień serwera. Na początku jednak przeceniano te podatności – założono, iż próg ich udanego zastosowania jest niewielki. Z tego powodu rozpoczęto analizę kodu PHP i próby przygotowania exploita 0-day. Wydaje się, iż tak wczesna informacja o wykryciu luki przy jednoczesnym braku dostępnej aktualizacji była co najmniej błędna, a poza tym tylko pogorszyła sytuację.
Z drugiej strony pojawiły się doniesienia o wykrytych próbach użycia podatności na cztery dni przed oficjalną informacją.
Błąd prowadzący do obu podatności jest dość skomplikowany i to kolejny raz, gdy AI wykrywa możliwą lukę w kodzie, która dla przeciętnego człowieka jest praktycznie niezauważalna. Inną szeroko komentowaną podatnością znalezioną z użyciem AI było Copy Fail.
Możemy spodziewać się wzrostu ilości podobnych podatności. Użycie sztucznej inteligencji w procesie odkrywania luk staje się popularną „rozrywką” dla osób uczestniczących w różnych programach bug bounty. jeżeli znaleziona w ten sposób podatność zostaje zgłoszona do producenta oprogramowania, to jest to rzecz jasna adekwatna ścieżka postępowania. Zgoła inaczej wygląda to jednak w sytuacji, gdy błędy znajdowane są przez osoby mniej zainteresowane udostępnianiem informacji o nich.
Trzeba pamiętać, iż medialnie krytyczna podatność może nie okazać się krytyczna w naszym środowisku. najważniejsze są zawsze usługi dostępne publicznie, gdzie dbanie o bezpieczeństwo jest oczywiście wymagane. Natomiast serwisów działających w sieci wewnętrznej, do których dostęp jest ograniczonych do autoryzowanych osób przebywających na terenie przedsiębiorstwa bądź też jest realizowany poprzez VPN, nie musimy traktować jako bezpośrednio zagrożonych. Jak zawsze istotna jest zasada minimalnego dostępu i monitoring usług.
Ktoś może zaryzykować stwierdzenie, iż dostawcy usług hostingowych nie powinni udostępniać starszych wersji systemu takiego jak PHP czy bazy danych. Problem w tym, iż nie każdą witrynę korzystającą ze starszego stacku technologicznego można łatwo zmodyfikować, aby działała poprawnie na jego nowszych odpowiednikach. Dodatkowo dla klienta koszt takiej modyfikacji może okazać się zwyczajnie zbyt duży. Firmy hostingowe w praktyce nie mogą sobie pozwolić na zaprzestanie utrzymywania starszych wersji. Kompromisem może być jednak migracja tych „przestarzałych” serwisów na dedykowane dla klienta serwery VPS, do których dostęp byłby ograniczony do adresów IP przez niego wskazanych. Dzięki temu na serwerach współdzielonych byłaby realna możliwość utrzymywania wyłącznie aktywnie wspieranego oprogramowania.
O bezpieczeństwo należy dbać, ale w rozsądnych granicach. Przede wszystkim unikać wystawiania publicznie usług, które równie dobrze mogą działać lokalnie – bazy danych, serwery SSH czy FTP. jeżeli już musimy udostępnić „wrażliwy” serwis publicznie, to postarajmy się o ograniczenie dostępu do konkretnych adresów. Dla aplikacji internetowych nieoceniona może być usługa WAF – współczesne komercyjne (i nie tylko) rozwiązania potrafią być naprawdę skuteczne i blokować formy ataku, o których istnieniu możemy choćby nie wiedzieć.
