Krytyczne RCE w rdzeniu interpretera PHP

21 października 2026 roku projekt PHP opublikował awaryjne aktualizacje 8.5.12, 8.4.27, 8.3.36 oraz 8.2.35, usuwające dwie krytyczne podatności bezpieczeństwa: CVE-2026-109618 i CVE-2026-109619. Obie otrzymały ocenę CVSS v4.0 9.2 (Critical) i zostały zbiorczo określone nazwą "PHP2Shell".

Nie jest to kolejna podatność w WordPressie, Drupalu, Laravelu czy Magenta. Problem znajduje się znacznie niżej, w samym interpreterze PHP, a konkretnie w mechanizmach zarządzania pamięcią, obsługi błędów i cyklu życia żądań HTTP.

W określonych warunkach atakujący może doprowadzić do nieprawidłowego przetworzenia wewnętrznych struktur pamięci, ujawnienia danych znajdujących się w pamięci procesu, a ostatecznie do wykonania własnego kodu z uprawnieniami procesu obsługującego żądania WWW.

Szczególnie niebezpieczna jest konfiguracja Apache z modułem mod_php, dla której potwierdzono możliwość przeprowadzenia ataku jeszcze przed rozpoczęciem wykonywania kodu aplikacji. Zagrożone są jednak również inne sposoby uruchamiania PHP, w tym PHP-FPM, php-cgi, FrankenPHP i LiteSpeed, przy czym warunki eksploatacji różnią się w zależności od środowiska.

Sama aktualizacja CMS-a, frameworka czy zainstalowanych wtyczek nie rozwiązuje problemu. Konieczna jest aktualizacja interpretera PHP oraz restart procesów korzystających z podatnego kodu.

PHP2Shell: dwie podatności, jeden fundamentalny problem

Obie podatności wynikają z nieprawidłowego zarządzania stanem pamięci interpretera, szczególnie podczas obsługi błędów krytycznych i nieoczekiwanego przerywania przetwarzania żądań.

Pierwsza, CVE-2026-109618, dotyczy sytuacji, w której mechanizm obsługi wyczerpania pamięci (OOM, Out of Memory) przerywa wykonywanie operacji, pozostawiając częściowo zainicjalizowane struktury wewnętrzne. Późniejsza procedura sprzątania pamięci może potraktować je jako poprawne.

Druga, CVE-2026-109619, związana jest ze stanem globalnym procesu PHP, który może zachować odwołania do pamięci zwolnionej po zakończeniu wcześniejszego żądania. Kolejne żądanie obsługiwane przez ten sam proces może wykorzystać nieaktualny wskaźnik, prowadząc do klasycznego błędu use-after-free.

Oba problemy dotyczą fundamentalnych operacji wykonywanych przez interpreter, niezależnie od logiki biznesowej aplikacji.

W oficjalnych advisory wskazano m.in. CWE-416 (Use After Free), CWE-755 (Improper Handling of Exceptional Conditions), CWE-824 (Access of Uninitialized Pointer), CWE-1325 oraz CWE-1419.

Badacze Wiz wskazują, że korzenie tych problemów sięgają co najmniej PHP 5.4. Oznacza to, że nie mamy do czynienia z regresją wprowadzoną podczas jednej z ostatnich aktualizacji, lecz z długo istniejącymi błędami projektowymi i implementacyjnymi, których pełne konsekwencje udało się wykazać dopiero w 2026 roku.

Od pierwszych sygnałów w 2024 roku do awaryjnych poprawek

Historia PHP2Shell jest równie interesująca jak sam mechanizm podatności.

Według PHP Foundation pierwsze oznaki problemu z obsługą OOM zidentyfikowano już w 2024 roku, podczas prac prowadzonych po audycie bezpieczeństwa realizowanym przez Quarkslab. Rozważano wówczas możliwość wykorzystania błędu, lecz nie znaleziono konkretnej, działającej ścieżki eksploatacji.

Naprawa okazała się trudna. Kolejne propozycje zmian mogły naruszać kompatybilność, wpływać na wydajność albo wymagać modyfikacji licznych rozszerzeń PHP. Projekt PHP Foundation sam przyznał później, że proces decyzyjny i ograniczone zasoby zespołu bezpieczeństwa doprowadziły do wielomiesięcznych opóźnień.

Dopiero badania przeprowadzone latem 2026 roku pokazały rzeczywistą skalę zagrożenia.

Chronologia wydarzeń

• 2024: Pierwsze przesłanki problemu OOM zostają zidentyfikowane podczas prac związanych z audytem bezpieczeństwa PHP. Nie udaje się jeszcze potwierdzić praktycznego RCE.

• 30 lipca 2026: Calif rozpoczyna audyt PHP w ramach programu Patch the Planet.

• 11 sierpnia 2026: Badacz Ryan A z Calif zgłasza ścieżkę RCE związaną z wcześniej zidentyfikowanym problemem OOM. Tego samego dnia OpenAI niezależnie zgłasza tę samą przyczynę źródłową.

• 19 sierpnia 2026: Wiz Research niezależnie identyfikuje podatność w interpreterze PHP.

• 20–21 sierpnia 2026: Wiz potwierdza nieuwierzytelnione RCE w środowiskach testowych wykorzystujących Drupala i WordPressa.

• 24 sierpnia 2026: Wiz przekazuje swoje ustalenia zespołowi bezpieczeństwa PHP.

• 18 września 2026: OpenAI zgłasza kolejne warianty wykorzystania błędów.

• 17 października 2026: Amazon Threat Intelligence rejestruje próbę wykorzystania PHP2Shell w infrastrukturze honeypot MadPot, cztery dni przed publicznym ujawnieniem.

• 20 października, około 15:00 UTC: W internecie zaczynają krążyć numery CVE oraz błędne informacje o terminie ujawnienia i ocenie CVSS 10.0. Według PHP Foundation na tym etapie nie wyciekły jeszcze techniczne szczegóły podatności.

• 20 października, 19:30 UTC: PHP publikuje wcześniejszy komunikat o zagrożeniu i przesuwa wydanie poprawek z 22 na 21 października.

• 20 października, wieczorem: Calif omyłkowo publikuje nagranie prezentujące działający proof of concept. Materiał zostaje usunięty, ale jego kopie zaczynają krążyć w internecie.

• 21 października, 07:41 UTC: Chainguard publikuje obrazy zawierające poprawki przed zakończeniem embarga. Umożliwia to analizowanie różnic między wersją podatną a naprawioną.

• 21 października, 14:00 UTC: Następuje skoordynowane ujawnienie podatności i publikacja awaryjnych aktualizacji PHP.

• 22–23 października: Badacze i dostawcy zabezpieczeń publikują kolejne analizy, narzędzia detekcyjne i informacje o działających exploitach.

• 23 października: Projekt PHP publikuje dodatkowy komunikat dotyczący CVE-2026-115560, czyli węższej ścieżki RCE, której nie usunięto poprawkami z 21 października.

W całej chronologii szczególnego znaczenia nabiera zdarzenie z 17 października. Amazon wykrył wtedy próbę wykorzystania podatności, która oficjalnie miała zostać ujawniona dopiero cztery dni później.

Nie wiadomo, czy sprawca dysponował niezależnie odkrytym exploitem, uzyskał informacje z innego źródła, czy skorzystał z wcześniejszego niekontrolowanego ujawnienia. Amazon nie potwierdził też, że zaobserwowana próba zakończyłaby się skutecznym przejęciem rzeczywistego serwera.

Sam fakt tak wczesnej aktywności podważa jednak założenie, że okres przed publikacją advisory jest automatycznie bezpieczny.

CVE-2026-109618: korupcja pamięci podczas obsługi Out of Memory

Pierwsza podatność wiąże się ze sposobem, w jaki interpreter PHP reaguje na wyczerpanie dostępnej pamięci.

Historycznie PHP wykorzystuje mechanizm longjmp() do szybkiego przerwania bieżącego przetwarzania w sytuacji OOM. Problem polega na tym, że takie przerwanie może nastąpić podczas operacji, w której nie wszystkie wewnętrzne struktury zostały jeszcze prawidłowo zainicjalizowane.

W normalnym scenariuszu odpowiednie funkcje inicjalizacji i czyszczenia pamięci wykonują się w przewidzianej kolejności. Jednak przy nieoczekiwanym OOM interpreter może opuścić wykonywany fragment kodu, pozostawiając stan, którego dalsza część silnika nie spodziewa się zobaczyć.

Następnie mechanizm request shutdown podejmuje próbę zwolnienia lub przetworzenia tych struktur, zakładając, że zawierają poprawne dane.

Jeżeli założenie jest błędne, może dojść do korupcji pamięci, nieprawidłowego odczytu wskaźników, awarii procesu, a w odpowiednio przygotowanych warunkach również do wykonania kodu kontrolowanego przez atakującego.

Dlaczego zwykłe ograniczenia PHP nie wystarczają?

Badacze wykazali, że w określonych przypadkach można doprowadzić do OOM podczas przetwarzania żądań multipart/form-data, nawet przy stosowaniu typowych limitów.

Znaczenie mają tutaj trzy mechanizmy:

1. Brak użytecznej deklaracji Content-Length

W określonych sposobach przesyłania treści HTTP początkowa kontrola rozmiaru żądania względem post_max_size nie musi obejmować całego strumienia danych w taki sposób, jak zakłada administrator. Bez odpowiednich ograniczeń po stronie serwera WWW lub reverse proxy interpreter może otrzymać dane prowadzące do nadmiernego zużycia pamięci.

2. Amplifikacja zużycia pamięci podczas parsowania multipart

Reprezentacja nagłówków i pól formularza wewnątrz interpretera może zajmować znacznie więcej pamięci niż ich pierwotna postać przesłana przez sieć. Rozmiar żądania HTTP nie przekłada się zatem liniowo na pamięć zużywaną podczas jego przetwarzania.

3. Rozbudowane struktury pól i metadanych

Zagnieżdżone nazwy pól formularza oraz metadane części plikowych mogą prowadzić do tworzenia licznych struktur wewnętrznych. Nawet puste części plikowe, nieuwzględniane w limicie max_file_uploads w taki sam sposób jak zwykłe pliki, mogą generować dodatkowe metadane.

Te właściwości nie oznaczają, że każde żądanie multipart prowadzi do RCE. Umożliwiają jednak osiągnięcie warunków potrzebnych do uruchomienia podatnej ścieżki obsługi OOM.

Dlaczego mod_php jest szczególnie zagrożony?

W konfiguracji Apache mod_php procedura zamykania żądania wykonywana jest również wtedy, gdy jego inicjalizacja zakończyła się niepowodzeniem.

Oznacza to, że nieprawidłowy stan powstały podczas parsowania danych wejściowych może zostać przetworzony w fazie request shutdown, jeszcze zanim aplikacja otrzyma możliwość uruchomienia własnego kodu PHP.

Dla tej konfiguracji potwierdzono pełne RCE przy standardowych ustawieniach PHP i normalnej konfiguracji Apache prefork z wieloma procesami obsługującymi żądania.

W przypadku PHP-FPM sytuacja jest inna. Jeśli błąd wystąpi podczas inicjalizacji żądania, proces potomny zwykle kończy pracę, co usuwa konkretną ścieżkę prowadzącą do późniejszego wykorzystania nieprawidłowego stanu. Nie wyklucza to jednak innych wariantów osiągnięcia OOM po pomyślnym rozpoczęciu obsługi żądania.

Oficjalne advisory dla CVE-2026-109618 wskazuje, że w chwili publikacji nie zademonstrowano kompletnego exploita tej konkretnej ścieżki na PHP-FPM. Nie oznacza to odporności całego środowiska PHP-FPM na PHP2Shell.

Podobne różnice występują w FrankenPHP i LiteSpeed/LSAPI, których cykle obsługi żądań nie są identyczne.

CVE-2026-109619: stary stan globalny, nowy kontekst pamięci

Druga podatność jest związana z mechanizmem use-after-free, ale jej charakter jest nieco inny.

Proces PHP może obsługiwać wiele kolejnych żądań HTTP. Chociaż pamięć należąca do poszczególnych żądań powinna zostać odpowiednio zwolniona, niektóre elementy stanu interpretera mają charakter globalny i pozostają związane z dłużej działającym procesem.

Dotyczy to między innymi obsługi sesji, błędów, obiektów i rozszerzeń.

W poprawnie działającym interpreterze odwołania do pamięci konkretnego żądania powinny zostać usunięte przed jej zwolnieniem. CVE-2026-109619 pozwala jednak na sytuację, w której operacja zostaje przerwana, zanim nastąpi prawidłowe wyczyszczenie stanu.

W rezultacie globalny wskaźnik nadal odwołuje się do pamięci, która formalnie nie należy już do zakończonego żądania.

Kolejne żądanie, jeżeli trafi na ten sam proces roboczy, może wejść w interakcję ze starym wskaźnikiem przed zakończeniem standardowej reinicjalizacji interpretera. Powstaje stan use-after-free.

Producer i consumer - dwa etapy jednego problemu

Oficjalne advisory opisuje ten mechanizm poprzez dwa pojęcia: producer oraz consumer.

Producer to operacja, która zapisuje stan związany z bieżącym żądaniem w miejscu dostępnym także dla późniejszych operacji. Jeśli nastąpi fatal error, OOM lub inny nieprawidłowo obsłużony przypadek, stan ten może pozostać aktywny mimo zwolnienia pamięci.

Consumer to późniejsza operacja, która korzysta z tego nieaktualnego stanu, zanim interpreter zdąży go poprawnie zresetować.

Badacze potwierdzili między innymi ścieżki związane z:

• session.upload_progress, czyli mechanizmem śledzenia postępu przesyłania plików;

• obsługą diagnostyki i ustawień INI przed standardową inicjalizacją żądania;

• fatal_error_backtraces w PHP 8.5.

W przypadku obsługi sesji szczególnie istotny jest fakt, że część operacji może rozpoczynać się już podczas parsowania wejścia HTTP, zanim interpreter zakończy typową inicjalizację modułów.

Na Apache mod_php potwierdzono zarówno scenariusze związane z obsługą błędów, jak i mechanizmem sesji.

Dla PHP-FPM potwierdzono natomiast RCE wykorzystujące cykl życia sesji, przy czym odpowiedni stan musi zostać wytworzony po prawidłowym rozpoczęciu obsługi żądania i wymaga odpowiedniej, osiągalnej ścieżki w aplikacji.

To istotne rozróżnienie: PHP-FPM nie jest automatycznie bezpieczny tylko dlatego, że inaczej zachowuje się podczas błędów inicjalizacji niż Apache mod_php.

Jak błędy pamięci zamieniają się w RCE?

Samo wystąpienie use-after-free nie gwarantuje wykonania kodu. W praktyce exploit musi przekształcić nieprawidłowy stan pamięci w możliwość kontrolowania przepływu wykonywania programu.

Badania PHP2Shell pokazują, że jest to możliwe poprzez połączenie kilku klas błędów i odpowiednie wykorzystanie sposobu zarządzania pamięcią przez Zend Engine. W uproszczeniu skuteczny łańcuch może obejmować trzy fazy.

1. Wytworzenie nieprawidłowego stanu

Specjalnie przygotowane żądanie doprowadza do sytuacji, w której interpreter pozostawia częściowo zainicjalizowane struktury albo nieaktualne wskaźniki.

W zależności od konkretnej ścieżki źródłem może być wyczerpanie pamięci, błąd krytyczny lub nieprawidłowo obsłużony stan sesji.

2. Ujawnienie pamięci i ominięcie ASLR

Atakujący stara się wykorzystać błędne odwołania do pamięci do uzyskania informacji o jej zawartości lub układzie.

Tego rodzaju wycieki mogą ujawniać adresy struktur i bibliotek procesu, co pozwala ograniczyć skuteczność ASLR, czyli mechanizmu losowania przestrzeni adresowej.

W analizach PHP2Shell opisano również scenariusze pozwalające ujawniać dane z pamięci procesu bez konieczności doprowadzania do pełnego RCE.

Jest to szczególnie niebezpieczne, ponieważ pamięć procesu PHP może zawierać tokeny uwierzytelniające, identyfikatory sesji, klucze API, hasła lub inne dane przetwarzane wcześniej przez aplikację.

3. Korupcja struktur i przejęcie wykonania

Po uzyskaniu wystarczającej kontroli nad stanem pamięci możliwe staje się doprowadzenie do nieprawidłowej interpretacji struktur wewnętrznych Zend Engine.

W odpowiednich warunkach pozwala to zmienić zachowanie interpretera i skierować wykonanie programu do kodu lub funkcji wybranych przez atakującego.

Wykonywany kod działa z uprawnieniami procesu obsługującego PHP, a nie automatycznie z uprawnieniami administratora systemu.

Nie zmniejsza to jednak znacząco ryzyka: przejęcie konta procesu WWW może umożliwiać dostęp do konfiguracji aplikacji, danych użytkowników, sekretów środowiskowych, plików dostępnych dla tego konta oraz dalsze przemieszczanie się w infrastrukturze, jeśli dodatkowe zabezpieczenia okażą się niewystarczające.

Czy ASLR i duża liczba workerów chronią przed atakiem?

Nie można na tym polegać.

ASLR zwiększa trudność eksploatacji, ale wykazano działające łańcuchy wykorzystujące ujawnienie informacji o pamięci do ominięcia tej ochrony.

Podobnie wiele procesów roboczych może utrudniać wykorzystanie CVE-2026-109619, ponieważ odpowiednie żądania muszą zostać obsłużone przez ten sam worker.

Większa liczba workerów zmniejsza jednak przede wszystkim przewidywalność ataku, a nie usuwa przyczynę podatności.

Również display_errors=Off nie stanowi skutecznej ochrony. Oficjalne advisory podkreśla, że część podatnych operacji wykonywana jest, zanim PHP podejmie decyzję o pokazaniu lub zapisaniu komunikatu diagnostycznego.

Exploity działają także w konfiguracjach produkcyjnych

Początkowo publiczne materiały demonstracyjne obejmowały między innymi ograniczone środowiska laboratoryjne, konkretne wersje PHP i ustawienia ułatwiające analizę pamięci. Sytuacja szybko się jednak zmieniła.

VulnCheck poinformował, że już 22 października dysponował działającym łańcuchem dla PHP 8.4.26 na architekturze x86-64, z włączonym ASLR oraz wyłączonym display_errors. To istotne, ponieważ są to ustawienia charakterystyczne dla normalnych środowisk produkcyjnych, a nie wyłącznie specjalnie uproszczonych laboratoriów.

Badacze Wiz potwierdzili ponadto skuteczne demonstracje RCE w środowiskach z WordPressem, Drupalem i Joomlą. Nie oznacza to, że wszystkie instalacje tych systemów mogą zostać przejęte jednym uniwersalnym żądaniem HTTP. Poszczególne łańcuchy zależą od wersji PHP, SAPI, rozszerzeń, konfiguracji serwera, aplikacji oraz układu pamięci.

Nie istnieje również jeden publicznie potwierdzony exploit gwarantujący skuteczność na każdej podatnej instalacji. Niemniej wykazanie działających łańcuchów dla realistycznych środowisk produkcyjnych oznacza, że PHP2Shell nie może być traktowany jedynie jako teoretyczna możliwość wynikająca z analizy kodu.

Próby eksploatacji rozpoczęły się przed ujawnieniem

21 października Amazon Threat Intelligence opublikował informację o próbie wykorzystania PHP2Shell zaobserwowanej cztery dni wcześniej, 17 października, w infrastrukturze MadPot. W kolejnych godzinach poprzedzających oficjalne ujawnienie rejestrowano dalsze próby pochodzące z różnych źródeł, w tym infrastruktury anonimizującej.

Po publikacji poprawek liczba pojawiających się narzędzi demonstracyjnych i prób ataków zaczęła szybko rosnąć. 22 października Check Point Research poinformował, że aktywność związaną z próbami eksploatacji zaobserwowano w środowiskach około 10% monitorowanych organizacji.

W tym miejscu konieczne jest ważne zastrzeżenie: statystyka nie oznacza, że przejęto 10% organizacji. Check Point wyraźnie wskazał, że chodzi o wykryte próby ataków, bez potwierdzenia ich skuteczności.

Podobnie obserwacja podejrzanego żądania na honeypocie, pojawienie się nowego exploita czy wykrycie skanowania nie są same w sobie dowodem masowej kompromitacji rzeczywistych serwerów.

Na 24 października 2026 roku dostępne informacje potwierdzają aktywne próby eksploatacji i istnienie skutecznych exploitów, lecz nie pozwalają wiarygodnie określić globalnej liczby przejętych systemów.

CVE-2026-115560: problem, którego poprawki z 21 października nie usuwają

23 października projekt PHP opublikował dodatkowy komunikat dotyczący CVE-2026-115560.

To odrębny, znacznie węższy scenariusz potencjalnego RCE, również związany z obsługą sesji i mechanizmem session.upload_progress.

Podatność wymaga nietypowego połączenia konfiguracji i zachowania aplikacji.

Problem może wystąpić, gdy aplikacja:

1. Korzysta początkowo z session.serialize_handler ustawionego na php_binary lub php_serialize.

2. Zmienia w trakcie wykonywania handler serializacji sesji na php przy użyciu ini_set(), jeszcze przed wywołaniem session_start().

3. Ma nadal włączony mechanizm session.upload_progress.

W takich warunkach istnieje dodatkowa ścieżka wykorzystania nieprawidłowego stanu, której nie naprawiono w wydaniach 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

Projekt PHP zapowiedział publikację pełnego advisory oraz poprawki podczas kolejnego regularnego cyklu wydawniczego.

Do tego czasu zalecono wyłączenie:

session.upload_progress.enabled = 0

Konfigurację należy zastosować w odpowiednim miejscu konfiguracji serwera, a następnie zrestartować procesy PHP.

PHP podkreśla, że CVE-2026-115560 wymaga nietypowej kombinacji ustawień. Aplikacje, które nigdy nie zmieniają handlera serializacji sesji w trakcie wykonywania, nie są narażone na tę konkretną ścieżkę.

Nie należy więc przedstawiać CVE-2026-115560 jako nowej, powszechnej podatności dotyczącej automatycznie wszystkich instalacji PHP.

Jednocześnie aktualizacja z 21 października pozostaje obowiązkowym działaniem, ponieważ skutecznie usuwa dwie pierwotne podatności PHP2Shell.

Jak skutecznie zabezpieczyć serwer PHP?

W przypadku CVE-2026-109618 i CVE-2026-109619 jedynym kompletnym rozwiązaniem jest zastosowanie poprawionego kodu interpretera.

Wszystkie pozostałe działania należy traktować jako środki ograniczające ekspozycję, przydatne przede wszystkim wtedy, gdy natychmiastowa aktualizacja nie jest możliwa.

1. Zaktualizuj interpreter

Minimalne poprawione wydania to:

Jeżeli system korzysta z pakietów dostarczanych przez dystrybucję Linuxa, producenta systemu hostingowego lub zewnętrznego dostawcę utrzymania, należy sprawdzić jego własne informacje bezpieczeństwa.

Dostawcy mogą stosować backporty, czyli przenosić poprawki do starszych wersji bez zmieniania głównego numeru wydania.

W takim przypadku sam numer wersji może nie wystarczyć do oceny podatności.

PHP 8.1 i starsze gałęzie nie są już standardowo wspierane przez projekt. Ze względu na skalę zagrożenia zespół PHP przygotował jednak minimalne poprawki źródłowe dla PHP 7.4, 8.0 i 8.1. Nie oznacza to wznowienia normalnego wsparcia dla tych wersji ani udostępnienia kompletu oficjalnych pakietów binarnych.

Dla instalacji korzystających ze starszych gałęzi należy w pierwszej kolejności sprawdzić dostępność zweryfikowanych poprawek u dostawcy oraz zaplanować migrację do wspieranej wersji PHP.

2. Zweryfikuj rzeczywiście działającą wersję PHP

Polecenie:

php -v

pozwala sprawdzić wersję interpretera uruchamianego z konsoli, ale nie musi pokazywać wersji obsługującej aplikację WWW.

Na serwerze mogą równolegle istnieć różne instalacje PHP wykorzystywane przez CLI, Apache, PHP-FPM lub FastCGI.

Dotyczy to również Windows Server z IIS, gdzie konfiguracja FastCGI i Handler Mappings może nadal wskazywać starszy plik php-cgi.exe, nawet jeżeli administrator zainstalował już nowsze binaria w osobnym katalogu.

Należy zweryfikować:

• aktywną wersję PHP dla każdej aplikacji WWW;

• rzeczywistą ścieżkę do wykonywanego interpretera;

• załadowany plik php.ini;

• ustawienia SAPI;

• aktywne pule PHP-FPM lub konfiguracje FastCGI;

• wersje i obrazy PHP uruchomione w kontenerach.

Weryfikację można przeprowadzić przez kontrolowany, dostępny tylko administratorowi test uruchomiony w tym samym środowisku co aplikacja. Jeżeli wykorzystywany jest phpinfo(), diagnostyczny plik należy usunąć natychmiast po zakończeniu kontroli i nie udostępniać go publicznie.

Po wdrożeniu poprawek konieczny jest restart odpowiednich procesów Apache, PHP-FPM, FastCGI lub odtworzenie kontenerów na bazie naprawionych obrazów.

Podmiana plików na dysku bez zakończenia starych procesów nie daje pewności, że podatny kod przestał być wykonywany.

3. Wyłącz session upload progress

Jeżeli funkcja nie jest niezbędna do działania aplikacji, należy ustawić:

session.upload_progress.enabled = 0

Zmianę należy wprowadzić na poziomie konfiguracji stosowanej przed parsowaniem żądań i zrestartować procesy PHP.

Nie należy polegać na zmianie wykonywanej dopiero przez kod aplikacji, np. za pośrednictwem ini_set(), ponieważ podatne operacje mogą wystąpić wcześniej.

Ograniczenie to blokuje potwierdzone ścieżki związane z mechanizmem sesji, a jednocześnie stanowi zalecany środek tymczasowy dla CVE-2026-115560.

Nie eliminuje jednak wszystkich wariantów CVE-2026-109619.

4. Zastosuj dodatkowe ograniczenia

W przypadku PHP 8.5 można rozważyć:

fatal_error_backtraces = 0

Wyłącza to jedną z potwierdzonych ścieżek związanych z zachowaniem stanu po błędach krytycznych.

Oficjalne advisory wskazuje również memory_limit=-1 jako możliwą tymczasową metodę ograniczenia kontrolowanego OOM w niezałatanych instalacjach.

Tego ustawienia nie należy jednak wdrażać bez analizy wpływu na dostępność systemu.

Usunięcie limitu pamięci na poziomie PHP może zwiększyć ryzyko wyczerpania pamięci całego procesu, kontenera lub serwera. Co więcej, rzeczywisty błąd alokacji pamięci nadal może uruchomić podatną ścieżkę.

Ograniczenia rozmiaru żądań, liczby pól, części multipart, nagłówków oraz poziomu zagnieżdżenia powinny być egzekwowane również na poziomie serwera WWW lub reverse proxy, uwzględniając żądania bez użytecznej deklaracji Content-Length.

W PHP-FPM pm.max_requests=1 może ograniczać niektóre scenariusze wymagające utrzymania stanu między żądaniami, ale oznacza też bardzo częste odtwarzanie workerów i potencjalnie istotny koszt wydajnościowy.

Nie jest to pełna ochrona.

Nie należy również traktować limitów RLIMIT_AS lub RLIMIT_DATA jako rozwiązania problemu. Według oficjalnego advisory mogą one doprowadzić do błędu alokacji i uruchomienia podatnej ścieżki.

5. WAF i reverse proxy

WAF może ograniczać część prób eksploatacji, szczególnie w przypadku podejrzanych żądań multipart i charakterystycznych wzorców obserwowanych podczas ataków.

Nie gwarantuje jednak zablokowania wszystkich wariantów PHP2Shell.

Administratorzy powinni rozważyć ograniczenie lub całkowite wyłączenie przesyłania danych multipart w usługach, które nie potrzebują takiej funkcjonalności.

Reguły bezpieczeństwa powinny uwzględniać również możliwe obejścia wynikające z odmiennego parsowania żądań przez frontend i interpreter.

Żadne z tych rozwiązań nie zastępuje aktualizacji PHP.

Jak wykrywać możliwe próby wykorzystania PHP2Shell?

Zastosowanie poprawki nie daje automatycznie pewności, że system nie został wcześniej zaatakowany.

Biorąc pod uwagę informacje Amazon Threat Intelligence, przegląd zdarzeń powinien obejmować co najmniej okres od 17 października 2026 roku.

Administratorzy powinni skoncentrować się na korelacji logów HTTP, procesów aplikacyjnych, systemu operacyjnego i narzędzi monitorujących.

Logi HTTP i reverse proxy

Warto zwrócić uwagę na:

• nietypową liczbę żądań POST z multipart/form-data;

• powtarzające się żądania z elementem PHP_SESSION_UPLOAD_PROGRESS;

• nagłe wzrosty liczby odpowiedzi HTTP 500, 502 i 503;

• nietypowe rozmiary żądań, błędy parsowania oraz przerwane transmisje;

• serie żądań poprzedzających awarie procesów PHP;

• podejrzane sekwencje wywołań następujących w krótkich odstępach czasu.

Żaden z tych objawów nie jest samodzielnym dowodem udanego ataku. Część może występować podczas normalnego korzystania z aplikacji albo w wyniku przypadkowych błędów.

Procesy PHP i system operacyjny

Należy sprawdzać:

• nieoczekiwane zakończenia i ponowne uruchamianie workerów;

• komunikaty o OOM, błędach alokacji i naruszeniach pamięci;

• nietypowe procesy potomne uruchamiane przez konto serwera WWW;

• nieoczekiwane pliki w katalogach aplikacji i obszarach tymczasowych;

• zmiany uprawnień, konfiguracji lub plików wykonywalnych;

• nieznane połączenia wychodzące inicjowane przez procesy serwera.

Szczególnego znaczenia nabiera wykrycie wykonania poleceń systemowych przez konto procesu WWW, jeżeli aplikacja nie realizuje takich operacji podczas normalnej pracy.

Ograniczenia logowania

Brak podejrzanych zdarzeń w logach nie dowodzi braku kompromitacji.

Niektóre podatne operacje mogą wystąpić przed pełnym uruchomieniem mechanizmów diagnostycznych PHP. Ponadto część komunikatów nie zostanie zapisana, jeśli system nie rejestrował odpowiedniego poziomu zdarzeń lub proces zakończył pracę przed ich utrwaleniem.

W środowiskach o podwyższonym ryzyku warto przeprowadzić dodatkową analizę integralności plików, procesów, połączeń sieciowych oraz danych uwierzytelniających dostępnych dla konta serwera.

W razie potwierdzenia kompromitacji sama aktualizacja interpretera nie wystarcza. Konieczna może być rekonstrukcja zaufanego środowiska oraz rotacja potencjalnie ujawnionych sekretów.

PHP2Shell pokazuje problem znacznie większy niż dwa CVE

Podatności w interpreterze PHP nie są niczym nowym. PHP2Shell wyróżnia się jednak połączeniem kilku właściwości.

Po pierwsze, błędy występują w fundamentalnych mechanizmach interpretera, wykorzystywanych przez ogromny ekosystem aplikacji internetowych.

Po drugie, podatności przez wiele lat pozostawały trudne do praktycznego wykorzystania. Dopiero połączenie analizy kodu, badań nad pamięcią, narzędzi automatyzujących i nowych technik opracowywania exploitów pozwoliło potwierdzić pełne łańcuchy RCE.

Po trzecie, sprawa pokazuje ograniczenia procesu utrzymywania bezpieczeństwa złożonych projektów open source. PHP Foundation przyznał, że wcześniejsze problemy organizacyjne i niedostateczne zasoby opóźniły prace nad rozwiązaniem problemu OOM. Jednocześnie opublikowane informacje wskazują, że po potwierdzeniu RCE w sierpniu 2026 roku naprawa otrzymała najwyższy priorytet.

Po czwarte, istotną rolę odegrały narzędzia sztucznej inteligencji. Calif, Wiz i OpenAI wykorzystywały zaawansowane metody analizy oraz wspomagania badań, a Wiz publicznie opisał rolę modeli AI w opracowywaniu i dostosowywaniu exploitów.

Nie oznacza to, że sztuczna inteligencja samodzielnie odkryła wszystkie podatności i automatycznie stworzyła uniwersalny exploit. Oznacza natomiast, że narzędzia AI zaczynają realnie obniżać koszt i czas potrzebny do analizowania skomplikowanych błędów pamięciowych.

To ma konsekwencje zarówno dla badaczy bezpieczeństwa, jak i dla samych atakujących. Podatność, której wykorzystanie wymagało kiedyś tygodni ręcznej analizy wykonywanej przez nieliczny zespół specjalistów, może stać się znacznie bardziej dostępna dzięki automatyzacji części procesu badawczego.

Nie unieważnia to znaczenia ASLR, separacji uprawnień czy ochrony pamięci. Pokazuje jednak, że wysoki koszt opracowania exploita nie powinien być traktowany jako trwała bariera bezpieczeństwa.

PHP2Shell należy traktować jako krytyczne zagrożenie dla infrastruktury korzystającej z podatnych wersji interpretera PHP, zwłaszcza wtedy, gdy usługi są dostępne bezpośrednio z Internetu.

Dwie pierwotne podatności, CVE-2026-109618 i CVE-2026-109619, umożliwiają w określonych warunkach nieuwierzytelnione RCE oraz ujawnienie danych z pamięci procesu. Badacze wykazali skuteczne łańcuchy eksploatacji także w realistycznych konfiguracjach produkcyjnych.

Dodatkowo komunikat z 23 października dotyczący CVE-2026-115560 pokazuje, że niektóre powiązane scenariusze obsługi stanu sesji wymagają dalszych działań, mimo zastosowania awaryjnych poprawek.

Najważniejsze działania administratorów to aktualizacja interpretera, restart wszystkich procesów wykorzystujących podatny kod, weryfikacja rzeczywiście uruchomionych wersji PHP oraz analiza logów pod kątem prób eksploatacji rozpoczętych jeszcze przed oficjalnym ujawnieniem.

Tam, gdzie aktualizacja nie jest możliwa, należy zastosować tymczasowe środki ograniczające ekspozycję, rozważyć odizolowanie usługi i potraktować dalsze udostępnianie jej w internecie jako świadomie akceptowane ryzyko.

PHP2Shell pokazuje również coś jeszcze: poprawny kod aplikacji nie oznacza bezpiecznego środowiska jej wykonania. Jeżeli podatność znajduje się w interpreterze, wszystkie kolejne warstwy zabezpieczeń aplikacji mogą okazać się niewystarczające. A aktualizowanie samego WordPressa, Laravela czy Drupala nie naprawi błędu znajdującego się w silniku, który te aplikacje uruchamia.

Źródła

1. PHP - Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)

2. PHP - Informational advisory: Session upload progress (23.10.2026)

3. GHSA-w8hw-w9fx-j79w - CVE-2026-109618

4. GHSA-6wmf-4rv5-p3rp - CVE-2026-109619

5. The PHP Foundation - Today's PHP Security Release, and How We're Strengthening PHP Security

6. Wiz Research - PHP2Shell: AI uncovers critical RCE vulnerabilities

7. Amazon Threat Intelligence - PHP2Shell exploitation prior to public disclosure

8. Check Point Research - PHP2Shell: One in ten organizations impacted

9. VulnCheck - Initial Access Intelligence, 17–23 October 2026