PHP2Shell to dwie krytyczne podatności w jądrze PHP, CVE-2026-109618 i CVE-2026-109619, które pozwalają zdalnie wykonać kod na serwerze bez uwierzytelnienia1, a podatne są wszystkie wersje PHP od 5.4 w górę2. Poprawki ukazały się 21 października 2026 roku w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.351, a podstawą jest aktualizacja, bo zmiany w php.ini tylko zmniejszają ryzyko12. PHP zaleca też wyłączyć postęp wysyłania sesji, session.upload_progress.enabled=0, nawet po aktualizacji, do następnego wydania1. Wersje 8.1 i starsze nie mają wydania od PHP. Pierwszą znaną próbę ataku zarejestrowano 17 października3, więc serwer sprawdzamy co najmniej od tej daty, a nie od dnia ujawnienia.
PHP2Shell dotyczy każdej strony i aplikacji, które odpowiadają na żądania HTTP przez PHP, także tych, których właściciel nie wie, na jakiej wersji działają: sklepów na WooCommerce, serwisów na WordPressie i Joomli oraz urządzeń sieciowych z wbudowanym PHP. Administrator musi więc jednocześnie ustalić, co u niego działa na PHP, zaktualizować to w kolejności od systemów widocznych z internetu i sprawdzić, czy ktoś nie uzyskał dostępu przed poprawką.
Co się stało: PHP2Shell w skrócie
21 października 2026 roku o godz. 14:00 UTC, czyli o 16:00 czasu polskiego, zespół PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, które zamykają dwie podatności w jądrze języka1. Obie umożliwiają zdalne wykonanie kodu (RCE) bez logowania, a PHP ocenia każdą na 9,2 w skali CVSS 4.01. Każda ma własny identyfikator CVE, a razem funkcjonują pod nazwą PHP2Shell.
Skala wynika z miejsca błędu. Dotyczą go wszystkie instalacje PHP obsługujące żądania webowe, w tym PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP i LiteSpeed1, a według Wiz każda wersja wydana w ostatniej dekadzie zawiera co najmniej jeden z błędów4.
W dniu ujawnienia ostrzeżenia opublikowały amerykańska agencja CISA i brytyjskie NCSC. CISA zaleca zinwentaryzować całe PHP w organizacji, także to osadzone w innym oprogramowaniu, zaktualizować najpierw systemy dostępne z internetu, a systemy, których nie da się od razu zaktualizować, oraz te, na których działa jeszcze PHP 8.1 lub starsze, wyłączyć do czasu załatania lub aktualizacji5. Brytyjski urząd wskazuje podobne kroki i dodaje sprawdzenie, czy w systemach nie ma śladów włamania i tylnych wejść6.
Dlaczego PHP2Shell jest groźniejsze niż zwykła luka w aplikacji
Atak, zanim ruszy kod aplikacji
Błędy leżą w etapie, który PHP wykonuje, zanim uruchomi jakikolwiek kod aplikacji. Przy starcie żądania interpreter parsuje jego treść, w tym dane typu multipart, a także obsługuje postęp wysyłania plików w sesji4. Według Wiz podatna jest nawet aplikacja typu "Hello World", bo atak wykonuje się na etapie, na który kod aplikacji nie ma żadnego wpływu4. Sam PHP opisuje w advisory wykazany exploit na mod_php, w którym nieuwierzytelnione żądanie wyzwala atak, zanim wykona się jakikolwiek kod aplikacji1.
Logowanie, role użytkowników i kontrola uprawnień w aplikacji nie zatrzymują ataku. Datadog odtworzył podatność i potwierdził, że uwierzytelnianie na poziomie aplikacji jej nie blokuje7. Wiz opisuje też wariant, w którym do ciasteczka PHPSESSID trafiają fragmenty pamięci serwera, nawet gdy aplikacja nigdy nie wywołuje session_start()4.
Dotyczy każdego sposobu uruchamiania PHP
PHP wymienia jako zagrożone wszystkie instalacje obsługujące żądania webowe, a za najbardziej narażone uznaje mod_php1. Advisory obu podatności opisują różnice między sposobami uruchamiania, które widać w zestawieniu poniżej.
| Sposób uruchomienia | CVE-2026-1096188 | CVE-2026-1096199 |
|---|---|---|
| mod_php | Zamknięcie żądania działa bezwarunkowo, także po nieudanym starcie, więc wyczerpanie pamięci podczas parsowania treści kończy się przetwarzaniem uszkodzonych danych przed kodem aplikacji. Wykazane przez HTTP przy domyślnych limitach PHP | Ustawienia z .htaccess i php_value obowiązują przed startem żądania, a potwierdzone wykorzystanie opiera się na PHP 8.5 i na postępie wysyłania sesji |
| PHP-FPM | Proces potomny kończy się po nieudanym starcie, ale brak pamięci po normalnym starcie nadal może wystąpić. Analiza kodu wskazuje podatność, pełnego exploita dla FPM nie wykazano | Ścieżka przez ustawienia INI działa tylko wtedy, gdy serwer frontowy przekazuje PHP_VALUE lub PHP_ADMIN_VALUE. Ścieżka przez postęp wysyłania sesji została zweryfikowana przy zwykłej dynamicznej puli, ale zależy od operacji w aplikacji |
| FrankenPHP | Jak mod_php zamyka żądanie bezwarunkowo, więc prawdopodobnie jest podatny | Advisory nie opisuje osobno |
| LSAPI (LiteSpeed) | Zachowuje się jak FPM | Ścieżka przez ustawienia INI jest warunkowa |
Brak wykazanego kompletnego exploita FPM dla CVE-2026-109618 nie oznacza, że ten sposób uruchamiania jest bezpieczny: według advisory analiza kodu przemawia za podatnością8, a dla CVE-2026-109619 ścieżka przez postęp wysyłania sesji została zweryfikowana na zwykłej puli FPM9.
Dwie podatności, dwa mechanizmy
| CVE | Nazwa w advisory PHP | Mechanizm | Warunek wywołania |
|---|---|---|---|
| CVE-2026-109618 | RCE via OOM corruption (GHSA-w8hw-w9fx-j79w) | Obsługa braku pamięci przerywa PHP, gdy dane żądania są zainicjowane tylko częściowo, a sprzątanie po żądaniu traktuje je jak poprawne | Żądanie, w którym brak pamięci wystąpi, zanim pamięć żądania zostanie w pełni zainicjowana |
| CVE-2026-109619 | RCE via stale global state (GHSA-6wmf-4rv5-p3rp) | Stan należący do żądania przeżywa zwolnienie pamięci, a kolejne żądanie na tym samym procesie używa go przed normalną inicjalizacją | Żądanie-producent i późniejsze żądanie-konsument obsłużone przez ten sam proces |
W CVE-2026-109618 PHP przerywa żądanie przy braku pamięci przez longjmp(). Jeśli alokacja zawiedzie w chwili, gdy pamięć żądania nie jest jeszcze w pełni zainicjowana, zostaje po niej stan nieprawidłowy, który zamknięcie żądania odczytuje i według którego się rozgałęzia8. Własne limity PHP nie wystarczają, bo żądanie multipart można zbudować tak, żeby obeszło zadeklarowane limity8. Skutkiem jest zdalne wykonanie kodu z uprawnieniami konta procesu WWW, zweryfikowane przez HTTP na mod_php przy domyślnych limitach wejścia i pamięci PHP8.
Poprawka usuwa longjmp() z obsługi braku pamięci i zastępuje go odroczonym, łagodnym zakończeniem w najbliższym bezpiecznym punkcie maszyny wirtualnej oraz natychmiastowym, twardym zakończeniem przez _exit() po przekroczeniu drugiego, wyższego progu8.
W CVE-2026-109619 stan globalny, który proces zachowuje między żądaniami, wskazuje na pamięć należącą do poprzedniego żądania. Część obsługi wejścia, konfiguracji, sesji i błędów działa przed normalną inicjalizacją kolejnego żądania i dotyka tego stanu, co daje użycie pamięci po zwolnieniu9. Potrzebny jest więc producent, który zapisuje stan żądania globalnie i nie czyści go po błędzie krytycznym, oraz konsument, który odczyta go przed inicjalizacją. Producenta i konsumenta zademonstrowano w osobnych żądaniach HTTP na tym samym procesie9.
Potwierdzonymi konsumentami są komunikaty diagnostyczne ustawień INI wypisywane przed inicjalizacją oraz postęp wysyłania sesji, a przed komunikatami nie chronią error_reporting, operator @, display_errors ani log_errors9. Najsilniejszy potwierdzony przypadek to funkcja fatal_error_backtraces w PHP 8.5, na której opiera się potwierdzone wykorzystanie na mod_php, a postęp wysyłania sesji jest domyślnie włączony i nie wymaga wywołania session_start()9. Zespół PHP pisze wprost, że nie istnieje kompletny ogólny środek ograniczający ryzyko w konfiguracji dla tej podatności9.
Czy mnie to dotyczy: podatne wersje PHP
CERT Polska w komunikacie 196/2026 pisze: "Podatne są wszystkie wersje PHP od 5.4 w górę"2. Ten sam zakres podaje Google Cloud, który wskazuje wersje od 5.4 do 8.5.1110, a Wiz pisze o wersjach wstecz do 5.44. Wcześniejszy komunikat CERT Polska 195/2026, wydany tego samego dnia przed publikacją poprawek, podawał wersje od 5.011, a późniejszy komunikat 196/2026 podaje 5.42. Advisory PHP wylicza w polu podatnych wersji tylko gałęzie wspierane, czyli te przed 8.2.35, 8.3.36, 8.4.27 i 8.5.128, ale starsze gałęzie także są dotknięte i nie dostaną wydania od PHP.
Dotyczy to także oprogramowania, które na PHP działa. CERT Polska wymienia WordPress, Joomla i WooCommerce jako dotknięte przez to, że opierają się na PHP2, a aktualizacja samej wtyczki lub motywu niczego tu nie zmienia, bo błąd leży w interpreterze.
Wersję PHP z wiersza poleceń pokazuje komenda:
php -v
Zwraca ona wersję programu uruchamianego z konsoli, a serwer WWW może używać innej instalacji PHP, więc trzeba sprawdzić również tę, którą wskazuje jego konfiguracja. Sposób uruchomienia widać w konfiguracji serwera WWW (moduł Apache, proces PHP-FPM podłączony do Nginx albo Apache, FrankenPHP lub LiteSpeed) albo w polu Server API w wyniku phpinfo() obsłużonym przez serwer WWW, przy czym plik z phpinfo() trzeba usunąć zaraz po sprawdzeniu, bo ujawnia konfigurację serwera. Dla gałęzi 5.6, 7.0, 8.0 i 8.1 CERT Polska wskazuje, że poprawki pochodzą od dystrybucji albo dostawcy oprogramowania2.
Wersje z poprawką
Poprawione wydania istnieją dla czterech wspieranych gałęzi, a dla trzech starszych są tylko backporty w źródłach12.
| Gałąź PHP | Wersja z poprawką | Status |
|---|---|---|
| 8.5 | 8.5.12 | Poprawione, wydanie z 21.10.2026 |
| 8.4 | 8.4.27 | Poprawione, wydanie z 21.10.2026 |
| 8.3 | 8.3.36 | Poprawione, wydanie z 21.10.2026 |
| 8.2 | 8.2.35 | Poprawione, wsparcie bezpieczeństwa kończy się 31.12.2026 |
| 8.6 | 8.6.0 RC4 | Poprawki zawarte w kandydacie do wydania |
| 8.1, 8.0, 7.4 | brak wydania | Minimalne backporty w źródłach php-src i poprawki dla dystrybucji |
| 7.3 i starsze, w tym PHP 5 | brak | Brak wydania PHP i backportu w źródłach. CERT Polska wymienia 5.6 i 7.0 wśród gałęzi, dla których poprawki pochodzą od dostawcy2, a zespół PHP nie przygotował dla nich backportu1 |
Dla gałęzi 8.1, 8.0 i 7.4 zespół PHP opublikował w repozytorium php-src osobne gałęzie z minimalnymi backportami, nazwane PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 i PHP-8.1-CVE-2026-109618-109619, a dystrybucje i dostawcy wsparcia długoterminowego dostali poprawki z wyprzedzeniem1. Dla PHP 7.3 i starszych, razem z PHP 5, zespół PHP takich gałęzi nie przygotował1, a dla 5.6 i 7.0 CERT Polska wskazuje poprawki od dostawcy dystrybucji lub oprogramowania2.
Gałąź 8.2 dostała poprawkę, ale wsparcie bezpieczeństwa dla niej kończy się 31 grudnia 2026 roku1, więc aktualizacja do 8.2.35 jest tu rozwiązaniem tymczasowym, a migrację na nowszą gałąź trzeba zaplanować od razu.
Co zrobić teraz
Kolejność ma znaczenie. Najpierw trzeba wiedzieć, gdzie PHP działa, potem je poprawić, a środki tymczasowe i zaporę stosuje się tam, gdzie poprawka nie jest jeszcze możliwa, z jednym wyjątkiem: PHP zaleca wyłączyć postęp wysyłania sesji do następnego wydania także po aktualizacji. Punktem wyjścia jest inwentaryzacja wszystkich miejsc, w których działa PHP, łącznie z tym, które jest wbudowane w inne oprogramowanie5. Priorytety ustala się jak w zarządzaniu podatnościami: najpierw systemy dostępne z internetu, bo tak wskazuje CISA5.
1. Zaktualizuj PHP i zrestartuj procesy
Dla gałęzi 8.5, 8.4, 8.3 i 8.2 potrzebne jest wydanie z poprawką: 8.5.12, 8.4.27, 8.3.36 albo 8.2.351, a poza nim wyłączenie postępu wysyłania sesji opisane w ramce niżej. Po aktualizacji trzeba zrestartować wszystkie procesy obsługujące PHP: PHP-FPM i serwer WWW, a dla FrankenPHP i LiteSpeed ich procesy, ponieważ stare procesy robocze zachowują stary kod i działają dalej z podatną wersją. Obraz kontenera trzeba przebudować i wdrożyć ponownie, co opisuje krok 4. Po restarcie trzeba potwierdzić wersję, której używa serwer WWW, a nie tylko tę z wiersza poleceń. Dla CVE-2026-109619 restart jest szczególnie istotny, bo błąd dotyczy stanu, który proces zachowuje między żądaniami9.
23 października PHP opublikowało komunikat informacyjny o kolejnym identyfikatorze, CVE-2026-115560, i sugeruje ustawić session.upload_progress.enabled=0 do następnego regularnego wydania z poprawkami błędów, aby w pełni zabezpieczyć się przed mało prawdopodobnym wektorem RCE, także w zaktualizowanych instalacjach1. Wektor wymaga konfiguracji, w której session.serialize_handler ustawiono w pliku na php_binary lub php_serialize, a aplikacja przełącza go na php przez ini_set() przed session_start(). Aplikacje, które nigdy nie zmieniają go w czasie działania, mogą zostawić postęp wysyłania sesji włączony, a pełny opis ma ukazać się z następnym wydaniem1.
2. Gdy aktualizacja nie jest możliwa: środki tymczasowe w php.ini i ich granice
PHP nazywa swoje zalecenia ograniczeniem ekspozycji, a nie zabezpieczeniem instalacji1. Dla CVE-2026-109618 ustawienie memory_limit=-1 nie jest kompletne, bo niepowodzenie mmap nadal trafia w podatny kod8, a dla CVE-2026-109619 advisory nie zna kompletnego środka ograniczającego ryzyko w konfiguracji9. CERT Polska zaznacza, że jego wartości również nie wykluczają wykorzystania podatności2.
Zalecenia PHP i CERT Polska zestawiamy osobno, bo nie są identyczne.
| Ustawienie | PHP | CERT Polska |
|---|---|---|
memory_limit |
-1, ustawione administracyjnie (np. przez php_admin_value), aby aplikacja nie mogła go zmienić |
-1, jeśli zasoby pozwalają, a w przeciwnym razie 128M lub więcej |
post_max_size |
Niska wartość: 8M bez wysyłania plików, 32M z wysyłaniem, a upload_max_filesize niższe od niej |
8M lub mniej |
max_input_vars |
Ograniczenie liczby zmiennych wejściowych, bez podanej wartości | 1000 lub mniej |
session.upload_progress.enabled |
0 w php.ini, puli lub konfiguracji serwera, z restartem wszystkich procesów roboczych |
Off |
fatal_error_backtraces (PHP 8.5) |
0, z restartem procesów |
brak zalecenia |
Dla session.upload_progress.enabled liczy się miejsce ustawienia: PHP wymaga zmiany w konfiguracji, a nie przez ini_set() ani .user.ini1. Niższe post_max_size z zalecenia CERT Polska blokuje wysyłanie plików większych niż ta wartość, a PHP podaje 32M dla aplikacji, które przyjmują pliki12.
PHP uzasadnia -1 tym, że usuwa ono kontrolowalne niepowodzenie przy przekroczeniu limitu pamięci, a skończony limit, także 128M z zalecenia CERT Polska, tę ścieżkę zostawia18. Brak limitu oznacza jednak, że jedno żądanie może zająć całą pamięć serwera. PHP zaleca obok niego niską wartość post_max_size, limity przed PHP oraz limit pamięci cgroup jako granicę dostępności, najlepiej taki, który zabija tylko proces roboczy, którego dotyczy problem; zabicie całej cgroup może zakończyć proces nadrzędny razem ze wszystkimi procesami roboczymi8. Trzeba też sprawdzić, czy żadna pula, żaden katalog ani żadna aplikacja nie przywraca skończonego limitu1.
Ustawienia to nie wszystko. PHP zaleca też limity po stronie serwera WWW lub proxy: rozmiaru żądania, liczby pól, części multipart, nagłówków i głębokości zagnieżdżenia, także dla żądań bez nagłówka Content-Length1. Nie wolno używać RLIMIT_AS ani RLIMIT_DATA, ponieważ powodują one właśnie to niepowodzenie alokacji, na którym opiera się podatność1. Trzeba sprawdzić, czy nie są już ustawione, na przykład przez ulimit -v w skrypcie startowym albo LimitAS w jednostce systemd.
Do tego należą usunięcie nieprawidłowych lub przestarzałych ustawień, które generują komunikaty przed inicjalizacją żądania, oraz naprawa błędów krytycznych i przekroczeń czasu, które atakujący może wywołać; wyciszenie komunikatów przez error_reporting, display_errors czy @ nie usuwa podatności1. Amazon dodaje, że jeśli aplikacja nie potrzebuje wysyłania plików, można zablokować żądania multipart, a w logach szukać żądań POST z polem PHP_SESSION_UPLOAD_PROGRESS w formularzach wysyłania3.
3. Wersje bez poprawki: 8.1 i starsze
Dla PHP 8.1 i starszych oraz wszędzie tam, gdzie nie da się od razu zaktualizować, CISA zaleca wyłączenie systemów opartych na PHP do czasu załatania lub aktualizacji5. W praktyce wybór ma trzy kierunki. Pierwszy to minimalny backport z gałęzi php-src (7.4, 8.0, 8.1) albo poprawka od dostawcy dystrybucji lub wsparcia długoterminowego, jeśli go wydał. Drugi to migracja na wersję z poprawką, najlepiej 8.3 lub nowszą, bo 8.2 traci wsparcie bezpieczeństwa 31 grudnia 20261. Trzeci, tymczasowy, to odłączenie systemu od internetu. Dla 7.3 i starszych, w tym PHP 5, zespół PHP poprawki nie przygotował1, więc pozostaje poprawka od dostawcy albo migracja.
4. Hosting, urządzenia i oprogramowanie z wbudowanym PHP
PHP bywa ukryte w czymś innym niż serwer WWW. CISA zaleca wliczyć do inwentaryzacji także PHP osadzone w innym oprogramowaniu5, a CERT Polska radzi w przypadku urządzeń i obrazów Docker czekać na nową wersję od dostawcy2. Według Google Cloud własne obrazy kontenerów i obciążenia w GKE trzeba przebudować i wdrożyć ponownie, a usługi bezserwerowe z automatyczną aktualizacją obrazu bazowego są poprawiane automatycznie10. Restart wewnątrz starego kontenera niczego nie zmienia. Palo Alto Networks podało, że dotknięte są wszystkie wersje PAN-OS i Panorama i że w czwartek 22 października o godz. 6:25 czasu wschodnioamerykańskiego (ET) nie było jeszcze wydania z poprawką12. Repozytorium remirepo w chwili publikacji tekstu Help Net Security z 21 października nie miało jeszcze aktualizacji12.
Te informacje pochodzą z 21 i 22 października, a dostawcy publikują wydania na bieżąco, więc przed decyzją trzeba sprawdzić stan u źródła. Jeśli serwer jest wynajęty, pytanie kontrolne do hostingodawcy brzmi: czy PHP na moim planie zostało zaktualizowane i czy procesy zostały zrestartowane.
5. Zapora aplikacyjna jako warstwa pomocnicza
Cloudflare wdrożył reguły zapory aplikacyjnej (WAF) dla znanych wektorów ataku, także w planach darmowych12. CISA dopuszcza WAF jako pomoc w czasie oczekiwania na aktualizację5. Reguły rozpoznają jednak wektory, które już znamy, a Wiz opisuje kilka wariantów błędów4, więc WAF kupuje czas, ale nie zastępuje poprawki.
Jak sprawdzić, czy serwer został już zaatakowany
Okno przeglądu zaczyna się co najmniej od 17 października, a nie w dniu ujawnienia. Tego dnia honeypot Amazon MadPot zarejestrował pierwszą próbę wykorzystania błędu, cztery dni przed publikacją poprawek, z komercyjnej sieci anonimizującej3. Skąd atakujący znał szczegóły, pozostaje niejasne. Aktualizacja zamyka drogę wejścia, ale nie usuwa niczego, co atakujący zdążył zostawić na serwerze, więc przegląd obejmuje także serwery już zaktualizowane.
Wskaźniki podają razem Wiz, CISA i Amazon453. Są to klasyczne wskaźniki włamania, czyli ślady, które w logach i w systemie zostawia przejęty serwer:
| Wskaźnik | Gdzie zajrzeć |
|---|---|
| Nietypowe żądania multipart, po których następują błędy limitu pamięci lub powtarzające się odpowiedzi 500 | Dziennik serwera WWW i dziennik błędów PHP |
Bardzo duże lub zniekształcone ciasteczka PHPSESSID w odpowiedziach serwera |
Dziennik serwera WWW lub proxy z zapisem nagłówka Set-Cookie |
| Częsta wymiana procesów roboczych PHP | Monitoring procesów |
| Proces PHP uruchamiający powłokę lub pobierający narzędzia | Monitoring procesów, system wykrywania zagrożeń na stacji |
| Nieoczekiwane zmiany plików na serwerze aplikacji | System plików, kontrola integralności plików |
Żądania POST z polem PHP_SESSION_UPLOAD_PROGRESS w formularzu wysyłania |
Dziennik zapory aplikacyjnej lub zapis treści żądań |
Po ustawieniu memory_limit=-1 błąd przekroczenia limitu pamięci już nie występuje, więc ten wskaźnik dotyczy dzienników sprzed zmiany. Pozostają nagłe zakończenia procesów roboczych i powtarzające się odpowiedzi 5004.
Procesy, które uruchamiają powłokę, i nowe pliki w katalogu witryny mogą oznaczać, że atakujący zostawił złośliwe oprogramowanie typu backdoor lub webshell. Przy potwierdzonym albo prawdopodobnym włamaniu przed jakąkolwiek zmianą trzeba zachować dzienniki i obraz dysku, bo po usunięciu zmian dowody znikają. Serwer odłącza się od sieci, a hasła, klucze i sekrety dostępne dla konta serwera WWW, czyli dane dostępowe do bazy, klucze API i sekrety aplikacji, zmienia się na nowe. Odtwarzanie zaczyna się od znanej, czystej kopii sprzed włamania, a nie od czyszczenia zainfekowanego systemu. Odtworzony serwer trzeba zaktualizować przed ponownym podłączeniem do sieci, bo kopia przywraca podatną wersję PHP.
Podejrzenie włamania to incydent bezpieczeństwa. CERT Polska prosi o zgłaszanie śladów wykorzystania podatności przez incydent.cert.pl2, a jak to zrobić krok po kroku, pokazuje nasz przewodnik po zgłaszaniu incydentów. Organizacje objęte NIS2 i ustawą o krajowym systemie cyberbezpieczeństwa mają osobne obowiązki zgłoszeniowe. Kto do nich należy, wyjaśnia artykuł o tym, kto wdroży NIS2 i ustawę o KSC, a akty prawne zestawia rejestr aktów prawnych krajowego systemu cyberbezpieczeństwa.
Niezależny przegląd zabezpieczeń po usunięciu skutków zleca się firmom z kategorii testy penetracyjne i audyty, a stały nadzór nad zdarzeniami prowadzą firmy z kategorii monitoring i SOC.
Chronologia: od sierpnia do 23 października
Z opisu Wiz wynika, że firma odkryła błąd 19 sierpnia 2026 roku, następnego dnia uzyskała zdalne wykonanie kodu w Drupalu, 21 sierpnia w WordPressie, 24 sierpnia zgłosiła go PHP, a zespół PHP potwierdził zgłoszenie 21 września4. Wiz wymienia modele Gemini 4 Argon i GPT-5.6 Sol oraz własne narzędzie Wiz Atlas jako wsparcie przy odkryciu4. Advisory PHP wskazują w podziękowaniach pracowników Wiz i OpenAI oraz programistów jądra PHP8.
Pierwszą znaną próbą jest ta z 17 października, opisana wyżej3. 20 października PHP zapowiedziało wydanie poprawek na 21 października, godz. 14:00 UTC1, a jeszcze przed planowanym ujawnieniem szczegóły objęte embargiem wyciekły do sieci, po czym watchTowr potwierdził, że opisane błędy są prawdziwe13. Amazon zidentyfikował kilka exploitów typu proof of concept, najwcześniejszy około godz. 2:00 UTC 21 października, jeszcze przed zdjęciem embarga, a między 2:00 a 8:00 UTC odnotował kolejne próby3.
Advisory na GitHubie opublikowano 21 października o godz. 13:34 UTC, 26 minut przed wydaniem8, a poprawione wersje ukazały się o 14:00 UTC1. Tego samego dnia CISA informowała, że nie zaobserwowała wykorzystania5, choć Amazon odnotowywał kolejne próby na swoich czujnikach3. 22 października pojawił się skaner Searchlight Cyber12, a 23 października PHP wydało komunikat informacyjny o CVE-2026-1155601.
Od 11 września 2026 roku producenci oprogramowania i sprzętu muszą zgłaszać w Unii aktywnie wykorzystywane podatności w terminach liczonych w godzinach, a kogo obejmuje ten obowiązek, wyjaśnia artykuł o zgłaszaniu podatności i incydentów według CRA.
Reakcja w Polsce: CERT Polska, COI i Ministerstwo Cyfryzacji
CERT Polska, czyli narodowy CSIRT, opublikował komunikat 196/2026 z 21 października, skierowany do administratorów. Wymienia w nim podatne wersje, podaje tymczasowe wartości php.ini i zaznacza, że ich zastosowanie nie wyklucza wykorzystania podatności2. Podaje też adres strony autorów odkrycia, php2shell.com, i prosi o zgłaszanie śladów ataku przez incydent.cert.pl2.
Skutki zobaczyli użytkownicy już w środę 21 października. O godz. 15:44 czasu polskiego Wykop wyświetlał komunikat o przerwie technicznej: serwis informował, że z powodu krytycznych podatności w PHP, z którego korzysta, tymczasowo się wyłącza, a powrót planował około godz. 17:00.
22 października ostrzeżenie opublikował minister cyfryzacji Krzysztof Gawkowski14, a Ministerstwo Cyfryzacji poprosiło każdego, kto zauważy ślady ataku, o zgłoszenie ich do CERT Polska1514. Tego dnia Centralny Ośrodek Informatyki (COI) poinformował, że "podjęliśmy decyzję o czasowym wyłączeniu stron Biuletynu Informacji Publicznej (BIP)"14. Dotyczyło to stron w systemie SSDIP, pod adresem ssdip.bip.gov.pl, a nie wszystkich BIP-ów14. Orange Polska czasowo zawiesiło wybrane usługi15.
Skala i co dalej
Według Wiz PHP napędza 70 procent wszystkich witryn na świecie, a firma widzi w PHP2Shell możliwy punkt zwrotny podobny do Heartbleed z 2014 roku i Log4Shell z 2021 roku4. Palo Alto Networks szacuje liczbę podatnych serwerów na ponad 22,6 miliona, co przytacza Rzeczpospolita15. Obie liczby są szacunkami, więc pokazują rząd wielkości, a nie pomiar.
Po stronie PHP otwarte pozostają dwie sprawy: pełne advisory dla CVE-2026-115560, które pojawi się z następnym wydaniem, oraz koniec wsparcia bezpieczeństwa dla gałęzi 8.2 z dniem 31 grudnia 2026 roku1.
Źródła
- PHP, "News Archive - 2026", 21.10.2026 - wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35, ocena CVSS 9,2, środki tymczasowe w konfiguracji i komunikat z 23.10.2026 (odczyt 23.10.2026)
- CERT Polska, "Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu - php2shell", 21.10.2026 - komunikat 196/2026 dla administratorów: podatne wersje, tymczasowe wartości php.ini (odczyt 23.10.2026)
- Amazon Web Services, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot", 21.10.2026 - pierwsza próba z 17.10.2026 i kolejne z 21.10.2026 (odczyt 23.10.2026)
- Wiz, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet" - mechanizm, zakres wersji, oś czasu odkrycia (odczyt 23.10.2026)
- CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", 21.10.2026 - zalecenia: inwentaryzacja, aktualizacja, wyłączenie systemów (odczyt 23.10.2026)
- National Cyber Security Centre (Wielka Brytania), "Critical security issue affecting PHP", 21.10.2026 - zalecenia dla organizacji (odczyt 23.10.2026)
- Datadog Security Labs, "PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): detection, analysis, and remediation" - odtworzenie podatności, brak ochrony przez uwierzytelnianie w aplikacji (odczyt 23.10.2026)
- GitHub, php/php-src, "RCE via OOM corruption", 21.10.2026 - advisory GHSA-w8hw-w9fx-j79w o CVE-2026-109618: mechanizm, sposoby uruchamiania, poprawka, środki ograniczające ryzyko (odczyt 23.10.2026)
- GitHub, php/php-src, "RCE via stale global state", 21.10.2026 - advisory GHSA-6wmf-4rv5-p3rp o CVE-2026-109619: producent i konsument stanu, potwierdzone przypadki (odczyt 23.10.2026)
- Google Cloud, "Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619" - zakres podatnych wersji, przebudowa obrazów kontenerów (odczyt 23.10.2026)
- CERT Polska, "Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu", 21.10.2026 - komunikat 195/2026 wydany przed poprawkami: wersje od 5.0, przygotowanie do aktualizacji (odczyt 23.10.2026)
- Help Net Security, "PHP2Shell: Critical PHP vulnerabilities patched, update now!", 21.10.2026 - remirepo, reguły Cloudflare, skaner Searchlight Cyber; aktualizacja z 22.10.2026: Palo Alto Networks (odczyt 23.10.2026)
- SecurityWeek, "PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws", 21.10.2026 - wyciek szczegółów przed ujawnieniem, potwierdzenie watchTowr (odczyt 23.10.2026)
- Android.com.pl, "Wyłączone strony rządowe w Polsce. Administratorzy łatają luki w PHP", 22.10.2026 - komunikat COI o wyłączeniu stron BIP (odczyt 23.10.2026)
- Rzeczpospolita, "Świat w cieniu PHPokalipsy. Polska wyłącza część serwisów", 22.10.2026 - reakcja ministra i ministerstwa, Orange Polska, szacunek Palo Alto Networks (odczyt 23.10.2026)