PHP2Shell (CVE-2026-109618 i CVE-2026-109619): co to za luki w PHP, kogo dotyczą i co zrobić dziś

21 października 2026 roku zespół PHP opublikował wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, które łatają dwie krytyczne podatności w rdzeniu języka, nazwane przez odkrywców PHP2Shell. Luki znaleźli badacze Wiz Research, OpenAI Codex Security i Calif. Szczegóły wyciekły do sieci jeszcze przed planowaną publikacją, dlatego PHP wydało poprawki z jednodniowym wyprzedzeniem (około 15:50 czasu polskiego), a firmy bezpieczeństwa już tego samego dnia raportowały pierwsze próby wykorzystania.

CERT Polska wydał dwa komunikaty (195/2026 i 196/2026) z zaleceniem natychmiastowej aktualizacji i — tam, gdzie się nie da — tymczasowej zmiany ustawień php.ini albo nawet wyłączenia usług PHP dostępnych z internetu. Skala jest bezprecedensowa: PHP obsługuje około 70% stron internetowych, w tym WordPress, WooCommerce, Joomla, Drupal, Moodle, Nextcloud, Laravel, Symfony i MediaWiki.

To nie jest luka we wtyczce ani w motywie. Podatny jest sam PHP, więc atak działa nawet na stronie z jedną linijką „Hello World”. Aktualizacja WordPressa, Joomli czy sklepu niczego tu nie zmienia — trzeba zaktualizować PHP pod spodem.

Obie podatności dotyczą zarządzania pamięcią w PHP i obie da się wywołać zwykłym żądaniem HTTP, bez konta w aplikacji. Różnią się mechanizmem:

Najgroźniejsza jest druga konsekwencja, o której mówi się mniej: wyciek pamięci procesu. W pamięci PHP leżą hasła do bazy danych, tokeny sesji, klucze API bramek płatności i certyfikaty — także należące do innych żądań. Badacze pokazali odczyt takiej pamięci niezależnie od aplikacji, bez wykonywania żadnego złośliwego kodu, co jest trudne do wykrycia narzędziami szukającymi infekcji.

Podatne są praktycznie wszystkie wersje PHP od 5.4 wzwyż i każdy sposób uruchamiania PHP obsługujący ruch z sieci: Apache z mod_php, PHP-FPM, php-cgi, FrankenPHP i LiteSpeed (LSAPI). Zespół PHP uznaje ryzyko za największe przy mod_php, gdzie potwierdzono przejęcie serwera domyślną konfiguracją, zanim jakikolwiek kod aplikacji się uruchomi.

Dystrybucje Linuksa (Debian, Ubuntu, RHEL, AlmaLinux, CloudLinux) często wstawiają łatkę do starszego numeru wersji. „PHP 8.1.2” z repozytorium Ubuntu może więc być bezpieczne, a „PHP 8.3.35” zbudowane ze źródeł — nie. Rozstrzyga lista zmian pakietu, a nie sam numer.

1. 1

   Ustal wersję PHP, na której działa strona.

   W WordPressie: Narzędzia → Zdrowie witryny → Informacje → Serwer. W panelu hostingu: ustawienia PHP domeny. Z konsoli: php -v (uwaga: wersja w konsoli bywa inna niż ta, która obsługuje stronę).

2. 2

   Porównaj z tabelą powyżej.

   Jeśli masz 8.2–8.5 poniżej wersji bezpiecznej — jesteś podatny. Jeśli masz 8.1 lub starsze, sprawdź u dostawcy, czy pakiet ma backport łatki.

3. 3

   Przy pakietach z dystrybucji sprawdź listę zmian.

   RHEL, AlmaLinux, CloudLinux: rpm -q --changelog php-common | grep -E "CVE-2026-10961[89]". Debian, Ubuntu: apt changelog php8.3-common | grep -E "CVE-2026-10961[89]". Pusta odpowiedź oznacza brak łatki.

4. 4

   Zinwentaryzuj wszystko, co ma w sobie PHP.

   Nie tylko strony: obrazy Dockera (np. php:8.3-fpm), panele administracyjne, phpMyAdmin, Roundcube, systemy newsletterowe, urządzenia typu appliance. Każde z nich ma własne PHP i każde wymaga osobnej aktualizacji.

Aktualizacja PHP jest jedyną pełną naprawą — wszystkie poniższe łagodzenia tylko zawężają drogi ataku. Kolejność działań dla administratora serwera:

1. 1

   Zainstaluj poprawione PHP.

   Ze źródeł php.net albo z pakietów dystrybucji: dnf update php* / apt upgrade. CloudLinux: yum update "alt-php*" (i ea-php* w cPanelu). Repozytorium Remi (rpms.remirepo.net) w dniu publikacji nie miało aktualizacji — zespół PHP zalecał przejście na pakiety dystrybucji albo kompilację ze źródeł.

2. 2

   Zrestartuj wszystkie procesy PHP.

   PHP-FPM (systemctl restart php-fpm lub php8.3-fpm), Apache z mod_php, procesy lsphp LiteSpeed, długo działające workery (kolejki Laravel, Swoole, RoadRunner). Bez restartu w pamięci dalej działa stary, podatny kod.

3. 3

   Zaktualizuj obrazy kontenerów.

   Pobierz nowy obraz bazowy (docker pull php:8.3-fpm), przebuduj własne obrazy i odtwórz kontenery. Przy gotowych aplikacjach w kontenerach poczekaj na nowe wydanie od producenta.

4. 4

   PHP 8.1 i starsze: zaplanuj przesiadkę.

   Projekt PHP nie wyda już dla nich poprawek. Na czas przejścia sprawdź, czy dostawca systemu (CloudLinux, TuxCare, Red Hat) ma backport — a potem przenieś stronę na PHP 8.3 lub 8.4.

5. 5

   Sprawdź po aktualizacji.

   Wersja PHP widoczna dla strony (nie tylko w konsoli), logi błędów, działanie formularzy i wysyłania plików. Poprawka wprowadza nowy, twardy limit pamięci: proces, który go przekroczy, kończy się natychmiast, bez uruchamiania funkcji zamykających — sprawdź importy i eksporty, które zużywają dużo pamięci.

Zespół PHP i CERT Polska podają zestaw ustawień, które blokują potwierdzone ścieżki ataku. Żadne z nich nie czyni instalacji bezpieczną — to most do czasu aktualizacji. Wpisz je w głównym php.ini albo w konfiguracji puli FPM (php_admin_value), nie przez ini_set() ani .user.ini, bo te działają za późno, już po przetworzeniu żądania.

; php2shell — tymczasowo, do czasu aktualizacji PHP
session.upload_progress.enabled = 0   ; CVE-2026-109619, ścieżka potwierdzona
fatal_error_backtraces = 0            ; tylko PHP 8.5
post_max_size = 32M                   ; 8M, jeśli strona nie przyjmuje plików
upload_max_filesize = 24M             ; zawsze mniej niż post_max_size
max_input_nesting_level = 16
display_errors = 0
expose_php = 0

• •session.upload_progress.enabled = 0 — blokuje potwierdzoną ścieżkę CVE-2026-109619. Funkcja jest włączona domyślnie, a prawie żadna strona z niej nie korzysta; zespół PHP radzi zostawić ją wyłączoną także po aktualizacji.
• •fatal_error_backtraces = 0 (PHP 8.5) — blokuje drugą potwierdzoną ścieżkę tej samej luki.
• •Niski limit post_max_size — 8M dla stron bez wysyłania plików, 32M, gdy pliki są potrzebne. Ogranicza pamięć, którą atakujący może zająć jednym żądaniem (CVE-2026-109618). Podobny limit warto ustawić na serwerze WWW lub proxy, także dla żądań bez nagłówka Content-Length.
• •memory_limit = -1 — zalecenie CERT Polska i zespołu PHP dla CVE-2026-109618: usuwa limit pamięci, na którym opiera się atak, ale przerzuca kontrolę na system operacyjny. Stosuj tylko razem z limitem cgroup (kontener, LVE, memory.max) i ustawieniem, którego aplikacja nie może nadpisać. Po aktualizacji wróć do skończonego limitu.
• •Nie używaj RLIMIT_AS ani RLIMIT_DATA jako zastępczego limitu pamięci — mogą wywołać dokładnie tę podatną ścieżkę.
• •Usuń przestarzałe dyrektywy ustawiane per katalog (np. php_value w .htaccess z auto_detect_line_endings, starymi assert.*, session.sid_length w PHP 8.4+ albo report_memleaks=0 w 8.5). Ostrzeżenia, które generują przed startem żądania, są jednym z wyzwalaczy CVE-2026-109619. Ukrycie ich przez error_reporting czy @ nie pomaga.
• •Niższe pm.max_requests w PHP-FPM — procesy częściej się odnawiają, więc uszkodzony stan krócej żyje. Kosztuje wydajność i nie chroni przed atakiem w jednym żądaniu.

CERT Polska w pierwszym komunikacie zalecał też rozważenie tymczasowego wyłączenia usług PHP dostępnych z internetu, jeśli nie zaburzy to działalności. Przy sklepie czy stronie firmowej zwykle się nie da — tym bardziej liczy się czas do aktualizacji.

Nie. Dostawcy zapór aplikacyjnych (Cloudflare, Imperva, Akamai, Imunify360) w dniu publikacji wydali reguły blokujące znany kształt publicznego exploita. To tzw. wirtualna łatka: zatrzyma automatyczne skanery i pierwszą falę ataków, ale żądanie zbudowane trochę inaczej przez nią przejdzie. CloudLinux przyznał na przykład, że jego pierwsza wersja reguł na serwerach LiteSpeed tylko zapisywała próbę w logu, zamiast ją blokować.

WAF warto mieć włączony i zaktualizowany — to dodatkowa warstwa. Ale strona za Cloudflare z niezałatanym PHP nadal jest podatna, a wyciek pamięci w ogóle nie musi wyglądać podejrzanie dla reguł szukających złośliwego kodu.

Nie istnieje jedna reguła, która wykryje każdy wariant, a podatny kod działa poniżej aplikacji, więc logi WordPressa czy sklepu zwykle niczego nie pokażą. Odkrywcy wskazują sygnały, od których warto zacząć analizę:

• •nietypowo duże lub zniekształcone ciasteczka PHPSESSID w odpowiedziach serwera,
• •nietypowe żądania multipart (formularze z plikami), po których pojawiają się błędy limitu pamięci albo serie odpowiedzi HTTP 500,
• •niewyjaśnione awarie i restarty procesów PHP (child exited on signal w logach FPM, padające lsphp).

# Odpowiedzi 500 na żądania multipart (formularze z plikami) — szukaj serii z jednego IP
grep -E '"POST [^"]*" 500 ' access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Błędy limitu pamięci i padające workery PHP
grep -E 'Allowed memory size of|Out of memory|exited on signal|child .* exited' error_log | tail -50

# Nietypowo długie ciasteczka PHPSESSID (w logach, które je zapisują)
grep -oE 'PHPSESSID=[^; "]{80,}' access_log | head

Brak tych śladów nie dowodzi, że serwer jest czysty — część ataków odczytuje pamięć bez pozostawiania wyraźnego wpisu. Jeśli coś znajdziesz, zgłoś incydent do CERT Polska przez incydent.cert.pl.

Jeśli strona działała na podatnym PHP po 21 października 2026, a szczególnie jeśli w logach są podejrzane sygnały, załóż, że sekrety z pamięci procesu mogły wyciec. Lista działań po aktualizacji:

1. 1

   Zmień hasło do bazy danych

   i wpisz nowe w wp-config.php / .env aplikacji.

2. 2

   Wygeneruj nowe klucze i sole WordPressa

   (AUTH_KEY, SECURE_AUTH_KEY i pozostałe) — to wyloguje wszystkich użytkowników i unieważni skradzione ciasteczka.

3. 3

   Unieważnij klucze API

   bramek płatności, kurierów, SMTP, systemów mailingowych, Google i innych integracji przechowywanych w konfiguracji.

4. 4

   Sprawdź konta administratorów

   i ostatnio zmienione pliki PHP (np. find . -name "*.php" -newermt 2026-10-20). Przeskanuj stronę skanerem złośliwego kodu.

5. 5

   Uporządkuj ustawienia tymczasowe

   przywróć skończony memory_limit, zostaw session.upload_progress.enabled = 0, ustaw expose_php = 0, utrzymuj post_max_size wyraźnie poniżej limitu pamięci.

6. 6

   Zaplanuj aktualizacje na stałe

   PHP 8.2 kończy wsparcie 31 grudnia 2026. Stały rytm aktualizacji PHP i spis wszystkich miejsc, gdzie PHP działa, skracają reakcję przy następnej takiej luce z dni do godzin.

Aderlo Cloud to polski hosting WordPress i WooCommerce na serwerach LiteSpeed z CloudLinuxem, na którym klienci wybierają wersję PHP od 7.4 do 8.5. Wieczorem 21 października 2026 roku zespół Aderlo Cloud wykonał na wszystkich serwerach z PHP następujące działania:

• •Natywne PHP 8.3 serwera zaktualizowane do 8.3.36 — tego samego dnia, w którym ukazała się poprawka.
• •Łagodzenia w php.ini dla wszystkich 14 wersji PHP dostępnych dla klientów (5.4–8.5): wyłączony session.upload_progress, a w PHP 8.5 fatal_error_backtraces. Ustawienia wpisane w główny php.ini, który obowiązuje przed przetworzeniem żądania — sprawdziliśmy je z wnętrza kont klientów, nie z konta administratora.
• •Audyt przestarzałych dyrektyw PHP w .htaccess, .user.ini i ustawieniach kont: żadna strona nie ustawia dyrektyw, które wyzwalają CVE-2026-109619 przed startem żądania.
• •Zapora aplikacyjna Imunify360 z regułami 8.85 z 21 października, które rozpoznają narzędzie PHP2Shell.
• •Automatyczna instalacja łatek CloudLinux dla wersji PHP z selektora: serwer co 20 minut sprawdza repozytoria i instaluje poprawione pakiety, gdy tylko się ukażą, po czym restartuje procesy PHP i porównuje odpowiedzi próbki stron klientów na każdej wersji PHP sprzed i po aktualizacji. Gdy któraś strona zacznie zwracać błąd, aktualizacja cofa się sama, a zespół dostaje alarm.
• •Aplikacje w kontenerach (np. NetSendo) dostały te same łagodzenia; obrazy aktualizujemy, gdy producent wyda wersję na poprawionym PHP.

Klienci Aderlo Cloud nie muszą niczego robić w sprawie samego PHP. Jeśli Twoja strona nadal działa na PHP 7.4 lub 8.0, to dobry moment, żeby przełączyć ją na 8.3 w panelu (Hosting → Twoja usługa → Domeny → Wersja PHP) — starsze wersje są łatane już tylko przez dostawcę systemu, a nie przez projekt PHP.