PHP2Shell: krytyczne luki RCE w PHP

W skrócie

21 października 2026 projekt PHP wydał awaryjne aktualizacje, które łatają dwie krytyczne luki pozwalające zdalnie uruchomić kod na serwerze bez logowania. Luki mają oznaczenia CVE-2026-109618 i CVE-2026-109619, a badacze nazwali je PHP2Shell. Błąd siedzi w samym PHP, więc aktualizacja WordPressa, Drupala czy innej aplikacji go nie naprawia.

Zaktualizuj PHP do wersji 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 (pobierz z php.net) i zrestartuj Apache, PHP-FPM oraz inne procesy PHP. Wersje 8.1 i starsze nie dostają oficjalnych poprawek od projektu PHP.

Co to za luki i jak groźne

To dwie luki w bezpieczeństwie pamięci w samym silniku PHP, a nie w kodzie aplikacji. Według PHP Foundation CVE-2026-109618 to uszkodzenie pamięci po jej wyczerpaniu: PHP zostawia częściowo przygotowane dane wewnętrzne i traktuje je potem jak poprawne. CVE-2026-109619 to użycie pamięci po zwolnieniu: stan z poprzedniego żądania wskazuje na zwolnioną pamięć, której używa kolejne żądanie. Szczegóły opisują ostrzeżenia GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp.

Powaga: krytyczna. PHP ocenia obie luki na 9,2 w skali CVSS v4.0, a do ataku nie potrzeba konta ani hasła. Największe ryzyko dotyczy Apache z mod_php, gdzie nieuwierzytelnione żądanie uruchamia atak, zanim wykona się jakikolwiek kod aplikacji (php.net). Zagrożone są jednak wszystkie tryby: PHP-FPM, php-cgi, FrankenPHP i LiteSpeed.

Czy ktoś już to wykorzystuje? Źródła mówią co innego. PHP Foundation nie znalazła działających exploitów w chwili wydania, choć po przecieku krążyły kody proof-of-concept. watchTowr zaobserwował wykorzystanie w praktyce 21 października, a Cloudflare widział ruch atakujący jego klientów jeszcze przed oficjalnym wydaniem. Stan na 21 października 2026, więc sprawdź aktualne komunikaty. Poprawki miały wyjść 22 października, ale przeciek identyfikatorów luk zmusił zespół PHP do przyspieszenia wydania o dzień.

Kogo to dotyczy

Dotyczy każdego serwera, który obsługuje żądania WWW przez PHP sprzed poprawki, niezależnie od zainstalowanej aplikacji. Według badaczy i Cloudflare podatne są wydania od PHP 5.4 wzwyż.

Gałąź PHP	Podatne wydania	Naprawione w
8.5	niższe niż 8.5.12	8.5.12
8.4	niższe niż 8.4.27	8.4.27
8.3	niższe niż 8.3.36	8.3.36
8.2	niższe niż 8.2.35	8.2.35 (koniec wsparcia 31 grudnia 2026)
8.1 i starsze	wszystkie	brak oficjalnej poprawki od projektu PHP

Dla PHP 7.4, 8.0 i 8.1 zespół PHP przygotował tylko minimalne łatki w kodzie źródłowym dla osób budujących PHP samodzielnie. Część dystrybucji i dostawców wsparcia długoterminowego dodaje poprawki do starszych wersji, więc zapytaj swojego dostawcę.

Podatne aplikacje: wszystko, co działa na PHP, na przykład WordPress, Drupal, Joomla, Moodle, Nextcloud, Laravel, Symfony i MediaWiki. Badacze pokazali zdalne wykonanie kodu bez logowania na WordPressie, Drupalu i Joomli (PHP2Shell).

Do czego może prowadzić wykorzystanie

Udany atak pozwala uruchamiać własny kod na serwerze z uprawnieniami procesu WWW, bez konta i hasła. Według badaczy możliwy jest też odczyt pamięci procesu bez uruchamiania kodu, co może ujawnić hasła, tokeny i klucze API. Typowe skutki przejęcia serwera WWW (przykłady z praktyki, nie ze źródeł): kradzież danych z plików konfiguracyjnych i bazy, trwały backdoor, spam i wydobywanie kryptowalut oraz atak na sąsiednie witryny. Izolacja (kontenery, osobne konta dla witryn) ogranicza skutki, ale nie zastępuje aktualizacji.

Jak się załatać

Jedynym pełnym rozwiązaniem jest wymiana PHP na wersję z poprawką i restart wszystkich procesów PHP. Aktualizacja aplikacji nie zmienia PHP pod nią (php.net).

1. Sprawdź wersję: php -v na serwerze, a w WordPressie Narzędzia → Zdrowie witryny → Informacje → Serwer.
2. Zaktualizuj PHP:
   • hosting: wybierz naprawioną wersję w panelu albo zapytaj dostawcę;
   • serwer z pakietami: aktualizacja z repozytorium dystrybucji lub dostawcy (według php.net repozytorium Remi nie miało aktualizacji w dniu wydania);
   • Docker: docker compose pull, potem odtworzenie kontenera (up -d) i php -v w nim. Przypięte wersje obrazów nie zmieniają się same;
   • ze źródeł lub Windows: pobierz wydanie z php.net (Windows).
3. Zrestartuj Apache, PHP-FPM i długo działające procesy PHP.
4. Sprawdź wersję jeszcze raz i zaktualizuj pozostałe środowiska PHP: cron, kontenery pomocnicze i testowe.

Oficjalne strony z poprawkami:

• PHP: pobieranie i lista zmian wydań 8.x
• PHP: komunikat bezpieczeństwa z 21 października
• Obrazy WordPressa na Docker Hub
• WordPress 7.1.3, osobne wydanie bezpieczeństwa rdzenia z 6 października

Jeśli nie możesz zaktualizować od razu

Środki tymczasowe zmniejszają ryzyko tylko dla wybranych ścieżek ataku i nie czynią instalacji bezpieczną. PHP pisze, że pełnych obejść nie ma, więc traktuj je jak doraźne zabezpieczenie na kilka godzin i przetestuj przed wdrożeniem.

• Zapora aplikacyjna (WAF). Cloudflare włączył domyślne reguły przeciw PHP2Shell dla klientów na wszystkich planach z WAF, także darmowym, od 21 października 3:02 UTC, około 9 godzin przed ujawnieniem. Działają na ruchu przechodzącym przez Cloudflare, więc domena musi mieć włączone proxy. Na planach Pro, Business i Enterprise sprawdź, czy Managed Ruleset działa w trybie blokowania. Cloudflare zaznacza, że to dodatkowa warstwa, a PHP trzeba i tak załatać.
• Ustawienia PHP (z php.net): memory_limit=-1 ustawiony tak, żeby aplikacja nie mogła go zmienić, niski post_max_size (8 MB, a gdy aplikacja przyjmuje pliki, 32 MB) i session.upload_progress.enabled=0 w konfiguracji serwera, z restartem workerów. W PHP 8.5 dodatkowo fatal_error_backtraces=0. Nie używaj RLIMIT_AS ani RLIMIT_DATA.
• Ograniczenie przesyłania plików zmniejsza ekspozycję, ale według Cloudflare nie zastępuje poprawki.

Po aktualizacji: jak sprawdzić, czy wszystko w porządku

Po aktualizacji potwierdź wersję PHP w dwóch miejscach i sprawdź, czy w okresie podatności nic nie zostało zmienione. Brak śladów nie dowodzi braku ataku, bo odczyt pamięci procesu może nie zostawić żadnych plików.

1. Wersja: php -v w środowisku serwera WWW i panel aplikacji (w WordPressie Zdrowie witryny). Obie wartości muszą się zgadzać.
2. Integralność plików: wp core verify-checksums i wp plugin verify-checksums --all porównują pliki z oryginałami niezależnie od dat modyfikacji.
3. Rzeczy, których nie powinno być: pliki .php w uploads, katalog mu-plugins, pliki db.php, advanced-cache.php i object-cache.php w wp-content, nieznani administratorzy oraz kod PHP zapisany w bazie (na przykład przez wtyczki do fragmentów kodu).
4. Logi serwera WWW: nietypowe żądania i ścieżki z .php w dziwnych miejscach, szczególnie z odpowiedzią 200.

Jeśli serwer mógł być osiągalny dla obcych, po aktualizacji zmień hasła, klucze API i tokeny używane przez aplikację. To rekomendacja ostrożnościowa autora, a nie wymóg z komunikatów.

Źródła

Stan na 21 października 2026. Strony php.net, PHP Foundation, PHP2Shell, watchTowr i Cloudflare zostały otwarte w całości przy pisaniu wpisu. Ostrzeżenia GHSA, Docker Hub, WordPress.org i zgłoszenie w repozytorium docker-library podaję za odnośnikami z tych stron i wynikami wyszukiwania, bez otwierania ich osobno.

• PHP.net: Security advisory: Critical remote code execution vulnerabilities, update now, komunikat z 21 października 2026, oraz zapowiedź z 20 października
• PHP.net: pobieranie i lista zmian wydań 8.x
• The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618) i GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability, 21 października 2026
• PHP2Shell, strona badaczy z Wiz Research, OpenAI Codex Security i Calif
• watchTowr: PHP CVE-2026-109618 FAQ, strona aktualizowana na bieżąco
• WordPress.org: WordPress 7.1.3 Maintenance and Security Release
• Docker Hub: obrazy WordPressa i docker-library/wordpress, zgłoszenie nr 1021