PHP2Shell: krytyczne luki w PHP, kogo dotyczą i co zrobić

Analiza zagrożenia: PHP2Shell to błąd w silniku, nie w aplikacji

Obie luki tkwią w mechanizmie zarządzania pamięcią samego PHP. Według advisory PHP pierwsza (CVE-2026-109618) wynika z obsługi braku pamięci: żądanie może zostać przerwane, gdy wewnętrzne dane są zainicjowane tylko częściowo, a sprzątanie po żądaniu traktuje te niepełne dane jak poprawne. Druga (CVE-2026-109619) polega na tym, że stan wewnętrzny jednego żądania może przetrwać po zwolnieniu pamięci i zostać użyty przez kolejne żądanie obsługiwane przez ten sam proces roboczy. Badacze z Wiz Research, OpenAI Codex Security i Calif, którzy zgłosili luki, zademonstrowali zdalne wykonanie kodu bez uwierzytelnienia na WordPressie, Drupalu i Joomli, ale podkreślają, że podatny jest sam PHP: narażona jest nawet prosta strona „Hello World" na podatnej wersji. Według badaczy PHP obsługuje około 70 proc. stron internetowych.

Według CERT Polska zagrożone są wszystkie wersje PHP od 5.4 w górę przed zastosowaniem poprawki; badacze zaznaczają, że warunki wykorzystania poszczególnych wariantów zależą od wersji i konfiguracji. Dotyczy to każdej instalacji obsługującej żądania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Zespół PHP uznaje ryzyko za najwyższe dla mod_php, gdzie pokazano exploit uruchamiany jednym żądaniem bez logowania, zanim wykona się jakikolwiek kod aplikacji. W PHP-FPM badacze potwierdzili zdalne wykonanie kodu przez ścieżki po stronie aplikacji. Oprócz wykonania kodu luki pozwalają odczytać pamięć procesu PHP, w której mogą być hasła, tokeny, klucze API i certyfikaty innych żądań lub samego serwera; taki wyciek nie wymaga wcześniejszego uruchomienia kodu i według badaczy może być trudniejszy do wykrycia narzędziami nastawionymi na złośliwy kod.

Poprawki ukazały się 21 października po południu czasu polskiego w wersjach PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Linie PHP 8.1 i starsze nie dostają już aktualizacji od projektu PHP; ze względu na wagę luk zespół bezpieczeństwa PHP opublikował minimalne poprawki źródłowe (backporty) dla PHP 7.4, 8.0 i 8.1 dla osób budujących PHP ze źródeł lub bez dostawcy LTS, a pozostałym radzi kontakt z dostawcą albo przejście na wspieraną wersję. Dystrybucje Linuksa i dostawcy LTS dostali poprawki z wyprzedzeniem. Według CERT-EU wolontariacki serwis rpms.remirepo.net nie będzie miał aktualizacji w dniu wydania, a zespół PHP wzywa jego użytkowników do przejścia na pakiety dystrybucji lub budowy ze źródeł.

Czy luki są wykorzystywane? Amazon Threat Intelligence zidentyfikowało w swojej sieci honeypotów próbę wykorzystania PHP2Shell datowaną na 17 października, cztery dni przed publicznym ujawnieniem, a 21 października kolejne próby z anonimizowanej infrastruktury; AWS zastrzega, że nie wiadomo, czy któraś z nich powiodłaby się na realnych systemach, i zaleca rozpoczynać dochodzenie co najmniej od 17 października. Cloudflare podaje, że obserwował ruch atakujący wobec swoich klientów i próby modyfikowania ładunków w celu ominięcia jego reguł. watchTowr, który odtworzył obie luki, w komunikacie z 14:19 UTC 21 października pisze, że obserwuje „aktywne próby wykorzystania" obu luk. CERT-EU ocenia, że publiczna dyskusja o szczegółach technicznych i krążące dowody koncepcji podnoszą prawdopodobieństwo wykorzystania. Według The Hacker News do 21 października żadne źródło nie potwierdziło włamania na konkretny serwer.

Kto odpowiada za aktualizację PHP: cztery scenariusze

Aktualizacja WordPressa, Laravela, sklepu czy wtyczki nie aktualizuje PHP, na którym działają. Poprawka przychodzi z pakietu dystrybucji, od hostingu, z obrazu kontenera albo od producenta urządzenia. W każdej z tych warstw decyduje ktoś inny, więc pierwsze pytanie brzmi: kto odpowiada za PHP w danym serwisie.

• Własny serwer z Apache mod_php lub PHP-FPM. Poprawkę instaluje się z pakietu dystrybucji albo ze źródeł, po czym trzeba zrestartować Apache, PHP-FPM i wszystkie długo działające procesy PHP. The Hacker News zwraca uwagę, że pakiet dystrybucji może mieć poprawkę pod starym numerem wersji; o jej obecności świadczy wpis z numerem CVE w changelogu pakietu, nie numer wersji.
• Strona lub sklep na hostingu współdzielonym. PHP utrzymuje dostawca. Cloudflare radzi, by w takim przypadku poprosić dostawcę o wdrożenie poprawki. Warto przy tym zapytać o wersję PHP i termin aktualizacji.
• Gotowe urządzenie, appliance lub aplikacja w obrazie Dockera. CERT Polska każe oczekiwać nowej wersji od producenta, a Rekomendacja Pełnomocnika Rządu ds. Cyberbezpieczeństwa dodaje, że po udostępnieniu należy ją niezwłocznie wdrożyć. CERT-EU zaleca sprawdzenie repozytorium NCSC-NL z listą oprogramowania firm trzecich, które ma wbudowane PHP i może być podatne, nawet jeśli nie wystawia PHP wprost.
• Stary system na PHP 8.1 lub starszym. Projekt PHP nie wydaje dla tych linii aktualizacji. CERT Polska wskazuje, że poprawki dla pozostałych linii, w tym 5.6, 7.0, 8.0 i 8.1, będą pochodzić od dostawcy dystrybucji lub oprogramowania używającego PHP. Kto buduje PHP 7.4, 8.0 lub 8.1 ze źródeł, może użyć minimalnych backportów od zespołu PHP; advisory PHP nie wymienia backportów dla linii starszych niż 7.4. Zespół PHP i CERT-EU wskazują drugą drogę: przejście na wspieraną wersję. Komu poprawki nie dostarczy ani dostawca, ani backport, zostaje migracja na wspieraną wersję; do tego czasu półśrodki lub odcięcie usługi od sieci publicznej.

Co to oznacza dla firmy: pilność, decyzja o wyłączeniu i Rekomendacja Pełnomocnika

Luka w silniku oznacza, że bezpieczny kod własnej aplikacji nie chroni. Firma, która zleciła audyt sklepu albo regularnie aktualizuje WordPressa, nadal jest narażona, jeśli pod spodem działa PHP bez poprawki. Druga cecha: atak nie wymaga konta ani logowania, więc celem może być także strona wizytówka, nie tylko portal klienta. Trzecia: możliwy jest wyciek pamięci procesu z hasłami, tokenami i kluczami API bez uruchamiania kodu na serwerze, co oznacza, że brak widocznych skutków nie dowodzi braku incydentu.

Pilność jest wysoka dla każdej instalacji PHP obsługującej żądania WWW, a najwyższa dla Apache mod_php. Advisory PHP wzywa wszystkich użytkowników do natychmiastowej aktualizacji, a tym, którzy nie mogą zrobić tego od razu, podaje półśrodki z zastrzeżeniem, że nie zabezpieczają instalacji. W ocenie redakcji rozsądna kolejność to mod_php, potem pozostałe usługi dostępne z internetu, na końcu serwisy wewnętrzne, ale wszystkie w tej samej kolejce.

Decyzję o wyłączeniu podjęła już instytucja państwowa. Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w Systemie Scentralizowanego Dostępu do Informacji Publicznej (SSDIP); według Ministerstwa Cyfryzacji niedostępność dotyczy wyłącznie stron w serwisie ssdip.bip.gov.pl, nie wszystkich stron BIP w Polsce, a wyłączenie ma pozwolić wprowadzić niezbędne zabezpieczenia. Strona gov.pl/bip zapowiadała przywrócenie możliwości przeglądania wcześniej opublikowanych informacji 22 października po godz. 16:00, przy nadal niedostępnej części redakcyjnej i części funkcji wyszukiwania; komunikat nie został uzupełniony o potwierdzenie przywrócenia (stan na 22 października, godz. 17:30).

W ocenie redakcji punktem odniesienia dla firmy rozważającej taki krok jest zalecenie CERT-EU: gdy natychmiastowa aktualizacja nie jest możliwa, organizacja powinna rozważyć odizolowanie aplikacji wystawionych do internetu od sieci publicznych do czasu wdrożenia i zweryfikowania poprawki. CERT Polska jeszcze przed wydaniem poprawek zalecał tymczasowe wyłączenie usług PHP dostępnych z internetu, „o ile nie zakłóci to działalności organizacji". W ocenie redakcji dla firmy pytanie nie brzmi, czy wyłączenie strony jest przesadą, lecz ile kosztuje dzień bez strony wobec przejęcia serwera i wycieku kluczy; ten rachunek zarząd musi zrobić sam.

Pełnomocnik Rządu ds. Cyberbezpieczeństwa wydał 22 października Rekomendację nr 2026/33/6 skierowaną do podmiotów krajowego systemu cyberbezpieczeństwa. Zaleca w niej natychmiastowe wdrożenie poprawki we wszystkich usługach z PHP, oczekiwanie na nowe wersje urządzeń i obrazów od producentów i ich niezwłoczne wdrożenie oraz, do czasu poprawki, ustawienie tych samych parametrów php.ini, które podaje CERT Polska. W dokumencie stwierdzono, że po konsultacji z CSIRT NASK, CSIRT GOV i CSIRT MON potwierdzono możliwość wystąpienia incydentu krytycznego w razie niezastosowania się do rekomendacji oraz że stosowanie oprogramowania z tymi podatnościami „ma negatywny wpływ na bezpieczeństwo publiczne i istotny interes bezpieczeństwa państwa". Podmiot KSC może wnieść zastrzeżenia na zasadach określonych w ustawie o KSC; tekst nie analizuje trybu, terminów ani skutków prawnych rekomendacji. Firma spoza krajowego systemu cyberbezpieczeństwa nie jest adresatem rekomendacji, ale jej treść techniczna jest taka sama jak zalecenia CERT Polska. Kto jest podmiotem krajowego systemu cyberbezpieczeństwa, opisuje wcześniejszy tekst Security Magazine o wykazie KSC.

Co z tego wynika dla decyzji:

• Konieczne: aktualizacja PHP i restart procesów na każdej instalacji obsługującej żądania WWW; według PHP, CERT Polska i badaczy to jedyna pełna ochrona.
• Zalecane do czasu poprawki: półśrodki w php.ini i limity na serwerze WWW, które nie zamykają wszystkich ścieżek ataku, a gdy natychmiastowa aktualizacja nie jest możliwa, odizolowanie usługi od sieci publicznej do czasu wdrożenia i zweryfikowania poprawki (CERT-EU).
• Opcjonalne: reguły WAF lub CDN dostawcy jako dodatkowa warstwa, która według badaczy i Cloudflare nie zastępuje aktualizacji PHP.

Czy ktoś już był: co sprawdzić po aktualizacji

Badacze zastrzegają, że jedna reguła detekcji nie pokryje wszystkich ścieżek wykorzystania. Jako sygnały do dochodzenia wskazują nietypowo duże lub zniekształcone ciasteczka PHPSESSID w odpowiedziach serwera, nietypowe żądania multipart, po których następują błędy limitu pamięci lub serie odpowiedzi HTTP 500, oraz niewyjaśnione awarie i restarty procesów roboczych PHP. Same sygnały nie dowodzą włamania, a ich brak nie dowodzi, że system jest nietknięty; część ataków może odczytać pamięć bez uruchamiania kodu, a logi aplikacji mogą nie zawierać kontekstu, bo podatne ścieżki działają poniżej warstwy aplikacji. CERT Polska prosi, by ślady wykorzystania luk zgłaszać niezwłocznie przez formularz na incydent.cert.pl.

Rekomendacje: aktualizacja PHP w trzech horyzontach

DZIŚ:

• Zinwentaryzować wszystkie usługi korzystające z PHP, jak zalecał CERT Polska; warto objąć tym także strony prowadzone przez zewnętrznych wykonawców i urządzenia z wbudowanym PHP, do czego CERT-EU wskazuje listę NCSC-NL.
• Dla usług PHP dostępnych z internetu: przed wprowadzaniem zmian zabezpieczyć logi PHP i serwera WWW, kopie konfiguracji i podejrzane pliki, jak zaleca watchTowr, i rozpocząć ich przegląd co najmniej od 17 października, zgodnie z zaleceniem AWS.
• Zaktualizować PHP do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 na każdej instalacji obsługującej żądania WWW, zaczynając od Apache mod_php. PHP wzywa do aktualizacji natychmiast.
• Po aktualizacji zrestartować Apache, PHP-FPM i wszystkie długo działające procesy PHP, zgodnie z zaleceniem badaczy.
• W ramach aktualizacji, jak zalecają badacze, przejrzeć memory_limit i post_max_size wobec potrzeb aplikacji: poprawka wprowadza twardy limit pamięci, którego przekroczenie kończy proces bez uruchomienia procedur zamykających.
• Przy pakiecie z dystrybucji sprawdzić w changelogu wpis z numerami CVE, nie numer wersji.
• Jeśli PHP utrzymuje hosting: poprosić dostawcę o wdrożenie poprawki, zgodnie z zaleceniem Cloudflare; warto też zapytać o wersję PHP i termin; bez odpowiedzi lub przy odległym terminie rozważyć odizolowanie serwisu od sieci publicznej do czasu wdrożenia i zweryfikowania poprawki, jak radzi CERT-EU.
• PHP 7.4, 8.0 lub 8.1 budowane ze źródeł lub bez dostawcy LTS: zastosować minimalne backporty zespołu PHP.
• PHP 8.1 i starsze z pakietu dystrybucji lub od dostawcy LTS: ustalić u dostawcy, czy i kiedy będzie backport; CERT Polska przewiduje poprawki od dostawców także dla linii 5.6 i 7.0.
• Gdy backportu nie ma: przejść na wspieraną wersję; do czasu migracji rozważyć odizolowanie serwisu od sieci publicznej, jak radzi CERT-EU.
• Dla urządzeń, appliance i obrazów kontenerów: ustalić u producenta, czy jest nowa wersja, i wdrożyć ją niezwłocznie po udostępnieniu, zgodnie z Rekomendacją Pełnomocnika.
• Jeśli natychmiastowa aktualizacja nie jest możliwa: rozważyć odizolowanie serwisu od sieci publicznej do czasu wdrożenia i zweryfikowania poprawki, jak radzi CERT-EU.

Półśrodki do czasu poprawki, według CERT Polska i advisory PHP; żaden z nich nie wyklucza wykorzystania luk:

• Ustawić memory_limit na -1, jeżeli pozwalają na to zasoby, a w przeciwnym razie na 128M lub więcej (CERT Polska). PHP radzi ustawić to tak, by aplikacja nie mogła nadpisać wartości (np. php_admin_value w puli FPM lub konfiguracji Apache), i sprawdzić, że żadne ustawienie puli, katalogu ani aplikacji nie przywraca limitu. Badacze ostrzegają, że -1 przenosi obsługę wyczerpania pamięci na system operacyjny i może odbić się na stabilności i dostępności serwera.
• Jako granicę dostępności użyć limitu kontenera lub cgroup, najlepiej z polityką kończącą tylko dotknięty proces; nie zastępować limitu przez RLIMIT_AS ani RLIMIT_DATA, bo według PHP mogą wywołać podatną ścieżkę.
• Ustawić post_max_size na 8M lub mniej (CERT Polska); według PHP 32M, jeśli aplikacja wymaga wgrywania plików, z upload_max_filesize poniżej post_max_size.
• Wprowadzić na serwerze WWW lub proxy limity rozmiaru zdekodowanego żądania, liczby pól, liczby części multipart, liczby nagłówków i głębokości zagnieżdżenia, także dla żądań bez użytecznego Content-Length (PHP).
• Ustawić max_input_vars na 1000 lub mniej (CERT Polska).
• Ustawić session.upload_progress.enabled na Off w php.ini, puli FPM lub konfiguracji serwera, nie przez ini_set() ani .user.ini, i zrestartować wszystkie procesy robocze; według PHP zamyka to potwierdzone ścieżki sesyjne, ale nie inne warianty.
• Na PHP 8.5 ustawić fatal_error_backtraces na 0 i zrestartować wszystkie procesy robocze (PHP).
• Usunąć nieprawidłowe lub przestarzałe ustawienia stosowane per żądanie, które generują komunikaty diagnostyczne przed inicjalizacją; według PHP ukrywanie diagnostyki przez error_reporting, display_errors lub @ nie pomaga.
• Naprawić błędy krytyczne i przekroczenia czasu wykonania osiągalne dla atakującego, w tym w callbackach, przetwarzaniu uploadów i importów oraz sprzątaniu (PHP).

W TYM TYGODNIU:

• Dokończyć przegląd logów co najmniej od 17 października, daty najwcześniejszej próby znanej AWS, pod kątem sygnałów opisanych wyżej; AWS wskazuje też na żądania POST z ciągiem PHP_SESSION_UPLOAD_PROGRESS w formularzach z plikami oraz nieoczekiwane uruchomienia procesów i zmiany plików na serwerach aplikacji, a watchTowr na nowe web shelle, nieoczekiwane zadania cron i nowe konta powiązane z procesami PHP. Brak sygnałów nie dowodzi, że system jest nietknięty. W razie śladów wykorzystania niezwłocznie zgłosić incydent na incydent.cert.pl.
• Śledzić komunikat CERT Polska 196/2026, który ma być aktualizowany o kolejne zalecenia i informacje o poprawkach w dystrybucjach.

DO ZAPLANOWANIA:

• Jeśli dziś działa backport od dostawcy lub zespołu PHP: migracja z PHP 8.1 i starszych na wspieraną linię; według The Hacker News linia 8.2 kończy wsparcie 31 grudnia 2026 r.
• Procedura wyłączenia usługi: kto decyduje, w jakim czasie, z jakim SLA hostingu, żeby następnym razem decyzja była gotowa, zanim pojawi się poprawka.

Podsumowanie

PHP2Shell wymaga aktualizacji PHP i restartu jego procesów na każdej instalacji obsługującej żądania WWW; półśrodki i reguły WAF tylko ograniczają ekspozycję. Próby wykorzystania obserwują AWS (najwcześniejsza z 17 października), Cloudflare i watchTowr; potwierdzonego włamania na konkretny serwer, jak podaje The Hacker News, do 21 października nie zgłosiło żadne źródło. Firma, której PHP utrzymuje hosting, producent urządzenia lub obraz kontenera, powinna dziś ustalić, kto i kiedy wdroży poprawkę, a bez odpowiedzi lub przy odległym terminie rozważyć odizolowanie serwisu od sieci publicznej do czasu wdrożenia i zweryfikowania poprawki, jak radzi CERT-EU.

Pytania, na które zarząd powinien znać odpowiedź:

• Które nasze serwisy działają na PHP i kto odpowiada za jego aktualizację: my, hosting, producent urządzenia czy wykonawca strony?
• Czy poprawka została wdrożona i czy po niej zrestartowano procesy PHP?
• Czy ktoś zabezpieczył i przejrzał logi co najmniej od 17 października pod kątem sygnałów opisanych przez badaczy, AWS i watchTowr?
• Ile kosztuje nas dzień bez strony i kto ma prawo podjąć decyzję o jej wyłączeniu?

Źródła

• PHP, Security advisory: Critical remote code execution vulnerabilities, update now (21.10.2026)
• CERT Polska, komunikat 196/2026: Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu - php2shell (21.10.2026)
• CERT Polska, komunikat 195/2026 (21.10.2026, przed wydaniem poprawek)
• CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP (21.10.2026, v1.1)
• Rekomendacja Pełnomocnika Rządu ds. Cyberbezpieczeństwa nr 2026/33/6 dotycząca podatności w oprogramowaniu PHP (22.10.2026, PDF)
• Ministerstwo Cyfryzacji, Ważny komunikat - luki w oprogramowaniu PHP (22.10.2026)
• Biuletyn Informacji Publicznej, komunikat o przywracaniu stron SSDIP (stan na 22.10.2026, 17:30)
• php2shell.com, Wiz Research, OpenAI Codex Security, Calif: PHP2Shell (21.10.2026)
• AWS Security Blog, CJ Moses: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (21.10.2026)
• Cloudflare, Cloudflare deploys protections against php2shell vulnerability (21.10.2026)
• The Hacker News, PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge (21.10.2026, z aktualizacjami; cytuje PHP Foundation)