PHP2Shell (CVE-2026-109618 i CVE-2026-109619): co firmy korzystające z PHP powinny zrobić już teraz

Technik z laptopem pracujący przy szafie serwerowej

21 października 2026 projekt PHP wydał wersje PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, usuwające dwie podatności, które „mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia”. Mówiąc wprost: każdy, kto może wysłać żądanie HTTP do Twojej strony, może być w stanie uruchomić własny kod na Twoim serwerze. Nie potrzebuje do tego hasła, a w niektórych konfiguracjach atak działa, zanim Twoja aplikacja wykona choćby jedną linię kodu. Para otrzymała nazwę PHP2Shell, a PHP ocenia obie luki na 9,2 (CVSS 4.0, w skali do 10).

Ten poradnik jest dla osób, które muszą na to zareagować: właścicieli stron i sklepów internetowych na PHP, kierowników IT i każdego, dla kogo PHP utrzymuje zewnętrzny dostawca. Powstał 22 października 2026, dzień po wydaniu poprawek, na podstawie biuletynów samego projektu PHP, zaleceń krajowych agencji cyberbezpieczeństwa i danych opublikowanych przez dostawców. Tam, gdzie źródła się różnią, piszemy o tym.

W skrócie

Zaktualizuj samo PHP, a potem je zrestartuj. Aktualizacja WordPressa, Drupala, Laravela czy wtyczki tego nie naprawia. Błąd tkwi w PHP, pod Twoją aplikacją.
Problem obejmuje każdą instalację PHP, która obsługuje żądania WWW, jak podaje PHP: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko PHP przypisuje konfiguracji Apache z mod_php.
Prawie połowa stron na PHP działa na gałęzi, dla której projekt PHP nie wydaje już nowych wersji (tak odczytujemy dane W3Techs, opisane niżej). Dla nich nie ma oficjalnego pakietu do zainstalowania.
Ustawienia i zapory dają czas, a nie bezpieczeństwo. PHP podaje środki tymczasowe i zaznacza, że „nie sprawiają one, że instalacja jest bezpieczna”.
Jeśli nie możesz załatać systemu dziś, agencje z USA, Wielkiej Brytanii i UE radzą to samo: odłącz system od internetu, dopóki nie będziesz w stanie go załatać.

Co się wydarzyło, po kolei

19 sierpnia 2026. Badacze z Wiz znajdują pierwszą z luk, jak podaje ich publikacja, i 24 sierpnia zgłaszają je zespołowi bezpieczeństwa PHP. W biuletynach PHP jako odkrywcy wymienieni są także badacze z kilku innych firm.
20 października. Numery CVE wyciekają do sieci dwa dni przed planowanym ujawnieniem. PHP przyspiesza wydanie o jeden dzień, na 21 października, godz. 14:00 UTC, i wzywa wszystkich do przygotowania się.
21 października, 03:02 UTC. Cloudflare włącza reguły zapory dla każdego klienta korzystającego z jego WAF, także w planie darmowym. Później informuje, że „zaobserwował ruch atakujący wymierzony w naszych klientów” i widział, jak atakujący „modyfikują payload ataku, próbując obejść nasze zabezpieczenia”.
21 października, około 14:00 UTC. PHP publikuje poprawki i swój biuletyn. Tego samego dnia amerykańska CISA, brytyjskie NCSC, CERT-EU oraz wspólne oświadczenie Komisji Europejskiej, ENISA, CERT-EU, Europolu i krajowych zespołów CSIRT państw UE wzywają organizacje do natychmiastowego wdrożenia poprawek.

Jak poważna jest sytuacja?

Trzy rzeczy odróżniają ją od zwykłych comiesięcznych poprawek.

Atakującemu wystarczy samo żądanie. Nie musi się logować i nikt nie musi klikać w link. Biuletyn PHP opisuje zademonstrowany exploit na Apache z mod_php, „w którym nieuwierzytelnione żądanie może uruchomić atak, zanim wykona się jakikolwiek kod aplikacji”. Wiz pokazał ataki na aktualne wersje systemów WordPress, Drupal i Joomla i zaznacza, że „nawet prosta aplikacja »Hello World« działająca na wersji PHP objętej lukami może być podatna”. Kod uruchomiony w ten sposób ma uprawnienia konta serwera WWW, które na większości stron może odczytać konfigurację aplikacji: hasło do bazy danych, klucze API, dane dostępowe do poczty i płatności. W przypadku drugiej luki, CVE-2026-109619, PHP potwierdza też ujawnianie pamięci: wyciek danych z pamięci serwera nawet bez pełnego wykonania kodu.

Liczba instalacji jest ogromna. Według W3Techs PHP działa na 69,3% stron internetowych, których język po stronie serwera jest znany (dane z 22 października 2026). Unit 42 z Palo Alto Networks na podstawie własnego skanowania internetu naliczył ponad 22,6 miliona instancji dostępnych z internetu, które są potencjalnie podatne, i podaje, że co najmniej jeden europejski rząd zapobiegawczo wyłączył swoją stronę internetową.

Prace nad exploitami idą szybko. CERT-EU podaje, że pierwsze exploity typu proof of concept „zaczęły krążyć”. Firma bezpieczeństwa watchTowr informuje, że jej honeypoty rejestrują próby wykorzystania luk od 21 października. Cloudflare informuje o ruchu atakującym. A Wiz podaje, że jego badacze przez cały czas korzystali z modeli AI, dzięki czemu jeden badacz zrobił w tydzień to, co „zajęłoby światowej klasy zespołowi miesiące”. Atakujący, którzy dostosowują exploit do Twojej wersji PHP, mają te same narzędzia.

Dla równowagi: gdy CISA opublikowała swój alert 21 października, nie zaobserwowała jeszcze wykorzystywania luk, a żadnej z nich nie było jeszcze w jej katalogu Known Exploited Vulnerabilities (znanych wykorzystywanych podatności). Red Hat ocenia problem jako „Important” (ważny), a nie krytyczny, bo standardowy serwer z Red Hat Enterprise Linux uruchamia PHP-FPM, gdzie wykorzystanie luk jest trudniejsze. Trudniejsze nie znaczy niemożliwe: PHP potwierdza, że jedna ze ścieżek ataku na drugą lukę działa także na PHP-FPM. Nic z tego nie zmienia tego, co należy zrobić. Zmienia tylko to, jak wcześnie dostaniesz ostrzeżenie.

Jakiej wersji używasz? Liczby

W3Techs publikuje też dane o tym, jakich wersji PHP używają strony internetowe, licząc strony, które ujawniają swoją wersję. Po zestawieniu jego dwóch tabel z 22 października 2026:

Gałąź PHP	Udział wśród stron na PHP	Poprawka od projektu PHP
8.3, 8.4, 8.5	około 34%	Tak: 8.3.36, 8.4.27, 8.5.12
8.2	około 18%	Tak: 8.2.35. Ale sama gałąź 8.2 osiąga koniec wsparcia 31 grudnia 2026
8.0, 8.1	około 14%	Brak wydania. 8.0 i 8.1: tylko backport w kodzie źródłowym
7.x	26,9%	Brak wydania. 7.4: tylko backport w kodzie źródłowym; 7.3 i starsze: nic
5.x i starsze	7,8%	Nic

Zatem około 48% stron na PHP działa na gałęzi, dla której projekt PHP nie publikuje poprawionego wydania, a kolejne 18% dostaje poprawkę teraz i traci wsparcie za dziesięć tygodni.

Dwa zastrzeżenia. W3Techs widzi tylko strony, które pokazują swoją wersję. A dystrybucja Linuksa mogła sama załatać starą gałąź: Ubuntu to zrobiło, jak zobaczysz niżej. Sam numer wersji nie mówi, czy Twój system jest chroniony. Mówi to wersja pakietu od Twojego dostawcy.

Krok 1: znajdź każdą instalację PHP

Nie załatasz czegoś, czego nie masz na liście, a PHP dobrze się ukrywa. Brytyjskie NCSC prosi organizacje o odnalezienie wszystkich systemów z PHP, w pierwszej kolejności tych dostępnych z internetu, i dodaje: „nie ograniczać wyszukiwania do przestarzałych wersji PHP”. Wspólne oświadczenie UE ostrzega, że niektóre produkty „mogą być dotknięte tymi podatnościami, nawet jeśli nie wydaje się, że bezpośrednio korzystają z PHP”.

Gdzie szukać:

Strony i sklepy: WordPress i WooCommerce, Drupal, Joomla, Magento i Adobe Commerce, Shopware, PrestaShop, TYPO3 oraz wszystko, co zbudowano na frameworkach Laravel lub Symfony.
Te zapomniane: mikrostrony kampanii, stara wersja językowa, serwery stagingowe i testowe dostępne z internetu, webmail albo helpdesk, który ktoś zainstalował przed laty.
Kontenery: każdy obraz zbudowany na obrazie bazowym php ma własne PHP. Aktualizacja hosta nic dla niego nie zmienia.
Panele hostingowe: cPanel, Plesk i podobne panele dostarczają własne kompilacje PHP obok systemowych. Każda wersja włączona w panelu to osobna rzecz do zaktualizowania.
Produkty z PHP w środku: urządzenia typu appliance, narzędzia monitorujące, systemy CRM, helpdeski i interfejsy administracyjne dostawców. Holenderskie NCSC prowadzi publiczną listę takich produktów wraz z ich statusem, z podziałem na dostawców.
Dostawcy: Twoja firma hostingowa, Twoja agencja, każda usługa, o której wiesz, że pod spodem działa PHP. Zapytaj ich na piśmie, na jakich wersjach PHP działają Twoje systemy i kiedy zostaną załatane.

Dla każdej pozycji zapisz wersję PHP, sposób uruchamiania PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, kontener), to, czy jest dostępna z internetu, i kto jest w stanie ją załatać.

Krok 2: łataj we właściwej kolejności

Zacznij od wszystkiego, co jest dostępne z internetu, a w tej grupie od konfiguracji Apache z mod_php.

Na wspieranej gałęzi (od 8.2 do 8.5). Zaktualizuj do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do pakietu Twojej dystrybucji, który zawiera poprawkę. PHP podaje, że dystrybucje Linuksa otrzymały łatki z wyprzedzeniem. Potwierdzone do tej pory:

Ubuntu: poprawione pakiety dla każdego wydania od 14.04 do 26.10. W 22.04 i nowszych przychodzą ze zwykłymi aktualizacjami; w 20.04 i starszych wymagają subskrypcji Ubuntu Pro, która jest bezpłatna dla maksymalnie pięciu maszyn (komunikat firmy Canonical).
Debian: php8.4 8.4.27 dla Debiana 13 (DSA-6574-1) i php8.2 8.2.35 dla Debiana 12 (DLA-4848-1).
Red Hat Enterprise Linux: biuletyn bezpieczeństwa Red Hat RHSB-2026-013 podaje pakiety dla poszczególnych wydań.
Repozytorium Remi, powszechnie używane do instalowania nowszych wersji PHP w systemach z rodziny Red Hat: 21 października CERT-EU odnotował, że w dniu wydania nie było w nim pakietów, i zalecił przejście na pakiety dystrybucji albo kompilację ze źródeł. Zanim się na nim oprzesz, sprawdź, czy już to nadrobiło.

Na PHP 7.4, 8.0 lub 8.1. Projekt PHP nie publikuje dla nich żadnego wydania. Jego zespół bezpieczeństwa przygotował dla tych trzech gałęzi minimalne backporty w kodzie źródłowym, które pomogą, jeśli kompilujesz PHP samodzielnie. W przeciwnym razie poprawka musi przyjść od Twojego dostawcy (na przykład Ubuntu Pro obejmuje PHP 7.4 w Ubuntu 20.04) albo z przejścia na nowszą wersję PHP. CISA radzi bez ogródek wszystkim na 8.1 lub starszych, którzy nie mogą zaktualizować: odłączyć system od sieci, dopóki nie zostanie załatany albo przeniesiony na nowszą wersję.

Na PHP 7.3 lub starszym. Od projektu PHP nie przyjdzie nic. Jeśli żaden dostawca nie łata już Twojej kompilacji, pozostaje wybór między przejściem na nowszą wersję a odłączeniem systemu od sieci.

Restart po aktualizacji. Instalacja pakietu nie podmienia PHP, które już działa. Komunikat Ubuntu ujmuje to wprost: aplikacja „prawdopodobnie będzie wymagała ponownego uruchomienia”. Zrestartuj PHP-FPM, Apache, LiteSpeed lub kontener na każdym serwerze. Potem sprawdź wersję, której faktycznie używa serwer WWW, a nie tylko php -v w wierszu poleceń, bo to może być inna kompilacja.

Kontenery: przebuduj obrazy na poprawionym obrazie bazowym i wdróż je ponownie. Załatany host, na którym działa stary obraz, nadal jest narażony.

Hosting zarządzany: zapytaj dostawcę o datę i wersję, a potem sprawdź to samodzielnie.

Krok 3: jeśli nie możesz załatać dziś

Biuletyn PHP podaje środki tymczasowe i poprzedza je ostrzeżeniem: „zmniejszają ekspozycję na określone ścieżki ataku, ale nie sprawiają, że instalacja jest bezpieczna”. W skrócie, dla osoby, która zarządza Twoimi serwerami:

Dla CVE-2026-109618: ustaw memory_limit=-1 tak, żeby aplikacja nie mogła tego nadpisać (na przykład przez php_admin_value w puli PHP-FPM lub w konfiguracji Apache); ustaw niski post_max_size (PHP sugeruje 8M bez przesyłania plików, 32M z przesyłaniem); ogranicz rozmiar żądania, liczbę pól i liczbę części multipart na serwerze WWW lub proxy; korzystaj też z limitu pamięci kontenera albo cgroup, nigdy z RLIMIT_AS ani RLIMIT_DATA.
Dla CVE-2026-109619: ustaw session.upload_progress.enabled=0 w php.ini lub w konfiguracji serwera (nie przez ini_set() ani plik .user.ini) i zrestartuj wszystkie workery. Na PHP 8.5 ustaw też fatal_error_backtraces=0.

Dwa ostrzeżenia. Ustawienie sesji, które szeroko się rozeszło 20 października, zamyka wyłącznie ścieżki ataku na drugą lukę, jak zauważył członek zespołu bezpieczeństwa PHP; przeciwko pierwszej nic nie daje. A memory_limit=-1 usuwa własny limit pamięci PHP, więc jedno ciężkie żądanie może teraz wyczerpać zasoby serwera. Połącz to z limitem kontenera lub cgroup.

Zapora aplikacji internetowych (WAF) pomaga, ale niewiele. Reguły Cloudflare są domyślnie włączone w każdym planie z jego WAF, także w darmowym, a Palo Alto Networks i inni dostawcy opublikowali własne zabezpieczenia. Cloudflare i tak zaleca klientom załatanie PHP „nawet przy ochronie WAF” i obserwował, jak atakujący zmieniają payloady, żeby prześlizgnąć się przez jego reguły. WAF chroni też tylko ruch, który przez niego przechodzi. Jeśli Twój serwer odpowiada pod własnym adresem IP, atakujący może go ominąć.

Jeśli nic z tego nie da się zrobić szybko, CISA, CERT-EU, NCSC i wspólne oświadczenie UE wskazują ten sam kierunek: odłącz system od publicznego internetu, dopóki nie zostanie naprawiony. Komunikat o przerwie technicznej przez jeden dzień kosztuje mniej niż odbudowa serwera.

Krok 4: sprawdź, czy nie doszło już do włamania

Okno otworzyło się 20 października, gdy zaczął się wyciek, a ruch atakujący zgłoszono następnego ranka. Jeśli system był w tym czasie dostępny i niezałatany, łatka zamyka drzwi, ale nie powie Ci, czy ktoś nie wszedł wcześniej. NCSC prosi każdego, kto nie mógł załatać od razu, o sprawdzenie, czy nie ma oznak włamania i backdoorów.

Czego szukać, na podstawie opublikowanych zaleceń i zwykłej praktyki reagowania na incydenty:

Procesy PHP, które robią coś, czego PHP nigdy nie robi, na przykład uruchamiają powłokę albo pobierają narzędzia (CISA).
Nietypowe żądania multipart, po których pojawiają się błędy limitu pamięci lub powtarzające się odpowiedzi HTTP 500, workery PHP restartujące się bez wyraźnego powodu oraz nietypowo duże lub zniekształcone ciasteczka PHPSESSID w odpowiedziach (Wiz).
Nowe lub zmienione pliki PHP w katalogach na przesyłane pliki, katalogach pamięci podręcznej lub w katalogu głównym witryny (web root), nowe konta administratorów w Twoim CMS i zaplanowane zadania, których nikt nie utworzył.

Czyste logi niczego nie dowodzą. Biuletyn PHP o drugiej luce ostrzega właśnie przed tym, a Wiz zaznacza, że logi aplikacji mogą zawierać niewiele kontekstu.

Jeśli coś znajdziesz, potraktuj to jako incydent, a nie zadanie łatania. Odizoluj serwer, zabezpiecz dowody, zaangażuj firmę specjalizującą się w reagowaniu na incydenty i zmień każdy sekret, który mógł odczytać serwer WWW: hasła do baz danych, klucze API, dane dostępowe do płatności i poczty, klucze do podpisywania. Ponieważ druga luka może ujawniać zawartość pamięci, rozważ rotację najbardziej wrażliwych z tych sekretów na każdym serwerze, który przez kilka dni był dostępny z internetu i niezałatany, nawet jeśli nie widać oznak włamania.

Krok 5: co być może trzeba zgłosić

Sama podatność nie jest incydentem podlegającym zgłoszeniu. Wykorzystana podatność może nim być.

NIS2: jeśli Twoja organizacja podlega NIS2, a włamanie jest poważnym incydentem, wczesne ostrzeżenie do krajowego CSIRT trzeba przekazać w ciągu 24 godzin. Zobacz nasz przewodnik po NIS2.
RODO: jeśli doszło do dostępu do danych osobowych, organ nadzorczy trzeba powiadomić w ciągu 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem dla osób fizycznych. Zobacz nasz przewodnik po RODO.
Cyber Resilience Act: jeśli sprzedajesz oprogramowanie lub urządzenie z PHP w środku, w rozumieniu CRA jesteś jego producentem. Od 11 września 2026 producenci muszą zgłaszać aktywnie wykorzystywane podatności w swoich produktach przez jedną platformę zgłoszeniową CRA, o czym przypomina wspólne oświadczenie UE. Zobacz nasz przewodnik po CRA.
Twoi klienci: jeśli hostujesz lub utrzymujesz PHP dla klientów, zapytają. Krótka pisemna notatka (na czym działają systemy, kiedy zostały załatane, co sprawdzono) odpowiada na większość pytań, a to ta sama notatka, którą zechce zobaczyć audytor albo ubezpieczyciel od ryzyk cybernetycznych.

Po kryzysie: co zmienić

Na większości dobrze utrzymanych serwerów PHP2Shell zostanie załatany w ciągu kilku dni. To, co ujawnił na temat Twojej infrastruktury, pozostanie aktualne także później.

Wiedz, ile trwa u Ciebie wdrożenie łatki. Od biuletynu do restartu każdego serwera: godziny, dni czy tygodnie? Jeśli uczciwa odpowiedź brzmi „musielibyśmy zapytać agencję”, napraw to przed następnym razem. Skoro badacze mówią, że AI skróciła ich pracę nad exploitem z miesięcy do tygodnia, załóż, że atakujący też mogą działać w takim tempie.
Zachowaj właśnie sporządzony inwentarz. Był najtrudniejszą częścią reakcji, a dezaktualizuje się w chwili, gdy nikt za niego nie odpowiada.
Porzuć wersje PHP, które straciły wsparcie. Strona na 7.4 lub 8.1 potrzebowała tym razem dostawcy albo backportu w kodzie źródłowym; następnym razem może nie być ani jednego, ani drugiego. PHP 8.2 osiąga koniec wsparcia 31 grudnia 2026, więc strona, która porzuca 8.1, powinna przejść od razu na 8.3 lub nowszą. Zmiana PHP często oznacza też aktualizację aplikacji: nasz artykuł o końcu wsparcia Drupal, Umbraco i Kentico pokazuje, co to oznacza w przypadku jednego systemu CMS.
Wybieraj PHP-FPM zamiast mod_php, gdzie to możliwe. Tym razem była to konfiguracja o niższym ryzyku.
Zostaw postęp przesyłania (upload progress) wyłączony, jeśli z niego nie korzystasz. Biuletyn PHP sugeruje, by session.upload_progress.enabled pozostało wyłączone także po załataniu, jeśli aplikacja tego nie potrzebuje.
Wpisz czasy wdrażania łatek do umów. Zapytaj dostawcę hostingu i agencję, jak szybko wdrażają krytyczne poprawki PHP, i uzyskaj odpowiedź na piśmie.

Lista kontrolna na ten tydzień

Spisz każdą instalację PHP, łącznie z kontenerami, panelami hostingowymi, produktami dostawców i serwerami stagingowymi.
Najpierw załataj systemy dostępne z internetu, zaczynając od Apache z mod_php.
Zrestartuj każdy proces PHP i sprawdź, jaką wersję serwer WWW zgłasza.
Przebuduj i ponownie wdróż obrazy kontenerów.
Tam, gdzie nie możesz załatać dziś, zastosuj tymczasowe ustawienia PHP, skieruj ruch przez WAF albo odłącz system od sieci.
Poproś dostawców i firmy hostingowe na piśmie o wersję PHP i datę załatania.
Przejrzyj logi i zmiany plików na wszystkim, co od 20 października było dostępne z internetu i niezałatane.
Zdecyduj, czy ma zastosowanie obowiązek zgłoszenia (NIS2, RODO, CRA).
Zaplanuj odejście od PHP 8.1 i starszych, a od 8.2 przed 31 grudnia.

W czym możemy pomóc

Większości firm nie brakuje chęci do łatania. Brakuje im jasnego obrazu tego, czego używają, albo ludzi, którzy wykonają tę pracę w tym tygodniu. Tę część bierzemy na siebie:

Inwentaryzacja i łatanie w kilka dni. Znajdujemy Twoje instalacje PHP na serwerach, w kontenerach, panelach hostingowych i u dostawców, łatamy je, restartujemy i weryfikujemy, a na koniec zostawiamy pisemny zapis tego, co i kiedy zostało zrobione. Ten zapis jest też Twoją odpowiedzią dla klientów i audytorów.
Odejście od starego PHP. Aplikacje, które utknęły na PHP 7.x, 8.0 lub 8.1, bo kod nie działa na niczym nowszym: przenosimy je na wspieraną wersję w ramach naszej usługi utrzymania systemów odziedziczonych.
Wzmocnienie zabezpieczeń i stały proces łatania, żeby następny biuletyn był zaplanowanym zadaniem, a nie sytuacją awaryjną.

Jeśli znajdziesz oznaki włamania, najpierw zadzwoń do firmy specjalizującej się w reagowaniu na incydenty. Równolegle z nią możemy przejąć odbudowę i przejście na nowszą wersję.

Napisz na office@c9group.dev, na czym działają Twoje systemy, a odpowiemy, od czego byśmy zaczęli.

Źródła

Sprawdzone 22 października 2026. Sytuacja wciąż się zmienia: zwłaszcza status wykorzystywania luk i pakiety dostawców mogły się od tego czasu zmienić.

Projekt PHP

Agencje

Badacze, dostawcy i dane