PHP2Shell - krytyczna podatność PHP. Jak sprawdzić, czy Cię dotyczy

21 października ujawniono dwie krytyczne luki w rdzeniu PHP, znane pod nazwą PHP2Shell: CVE-2026-109618 i CVE-2026-109619. Zespół PHP ocenia obie na 9.2 w skali CVSS v4.0, a część zespołów badawczych na 10.0. Według zgłaszających podatna jest każda wersja PHP od 5.4 w górę, a więc praktycznie wszystko, co dziś działa na produkcji. Doniesienia z dnia publikacji mówią, że ataki już trwają.

Co to właściwie jest

To nie jest luka w jednej bibliotece czy wtyczce. To błędy w samym silniku PHP, czyli w komponencie, który uruchamia kod każdej aplikacji napisanej w tym języku - od sklepu, przez stronę na WordPressie, po wewnętrzny panel administracyjny.

Technicznie to dwa błędy obsługi pamięci przy przetwarzaniu żądania. W jednym przypadku dane żądania są inicjalizowane tylko częściowo (np. przy wyczerpaniu pamięci), a późniejsze sprzątanie traktuje je jak poprawne. W drugim wewnętrzny stan żądania potrafi przetrwać po zwolnieniu pamięci, która go przechowuje (klasyczny use-after-free). Oba prowadzą w stronę zdalnego wykonania kodu, stąd nazwa PHP2Shell.

Przecieki wskazują na mechanizm session.upload_progress - funkcję śledzenia postępu wysyłania plików, która jest w PHP od wersji 5.4.0 i jest włączona domyślnie. To właśnie dlatego skala ekspozycji jest tak duża: nie trzeba było niczego specjalnie konfigurować, żeby być podatnym.

Jak sprawdzić, czy Cię dotyczy

Kilka kroków, które możesz zrobić samodzielnie, bez żadnych specjalistycznych narzędzi.

1. Sprawdź, czy i gdzie w ogóle masz PHP

Na serwerze (SSH) wystarczy:

php -v

Jeśli widzisz numer wersji - PHP jest zainstalowany. Pamiętaj, że PHP często działa „niewidocznie”: pod stroną firmową na WordPressie, Joomli czy Drupalu, pod sklepem na PrestaShop lub Magento, pod starym intranetem albo pod aplikacją postawioną lata temu przez zewnętrznego wykonawcę. Jeśli korzystasz z hostingu współdzielonego, zapytaj dostawcę wprost, jaką wersję PHP serwuje i czy już ją zaktualizował.

2. Porównaj wersję z załatanymi

Bezpieczne wydania opublikowane 21 października to:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Jeśli Twoja wersja jest niższa w obrębie danej gałęzi (np. 8.2.30) albo należy do gałęzi już nieobsługiwanej (8.1 i starsze, w tym cała rodzina 7.x i 5.x), jesteś podatny. Wersje po końcu wsparcia nie dostaną poprawki w ogóle - szacuje się, że dotyczy to setek tysięcy hostów.

3. Zobacz, co masz wystawione do internetu

Przejrzyj, które z Twoich usług są dostępne publicznie. Pomaga w tym spis własnych domen i subdomen oraz prosty przegląd nagłówków odpowiedzi - serwery często same zdradzają wersję:

curl -sI https://twojadomena.pl | grep -i "server\|x-powered-by"

Jeśli w odpowiedzi widać X-Powered-By: PHP/8.2.x lub podobnie, to po pierwsze masz tam PHP, a po drugie - warto ten nagłówek wyłączyć (o tym niżej).

Co zrobić

1. Zaktualizuj PHP do jednej z wersji wymienionych wyżej. To jedyne pełne rozwiązanie. Na większości systemów to kwestia menedżera pakietów (apt, dnf) i restartu php-fpm oraz serwera WWW.
2. Doraźnie, jeśli aktualizacja nie może nastąpić w tej chwili, wyłącz podatny mechanizm w php.ini:

   session.upload_progress.enabled = Off

   Uwaga: według zespołów reagujących to ogranicza część ścieżek ataku, ale nie czyni instalacji bezpieczną. Traktuj to jako kupienie czasu, nie jako naprawę.
3. Ogranicz powierzchnię: wyłącz nagłówek expose_php = Off, odetnij od internetu panele i usługi, które nie muszą być publiczne.
4. Systemy, których nie da się szybko załatać, rozważ czasowo wyłączyć - taką rekomendację wydał m.in. brytyjski NCSC dla przypadków bez możliwości natychmiastowej poprawki.
5. Sprawdź, czy już nie doszło do włamania: przejrzyj logi dostępu pod kątem nietypowych żądań, poszukaj nowych lub zmodyfikowanych plików w katalogach aplikacji (zwłaszcza plików .php w miejscach, gdzie być ich nie powinno) i nietypowych procesów. Przy podejrzeniu kompromitacji sama aktualizacja nie wystarczy - trzeba przeprowadzić analizę.

Dlaczego to poważne akurat dla ochrony zdrowia i mniejszych organizacji

Największe ryzyko nie dotyczy firm z działem IT, który dziś rano już załatał serwery. Dotyczy organizacji, które nie wiedzą, że mają gdzieś PHP: przychodni ze stroną postawioną kiedyś przez zewnętrzną firmę, gabinetów z systemem rejestracji online, małych podmiotów, w których „stroną zajmuje się znajomy”. To właśnie tam podatny PHP potrafi działać latami, a przy tej luce wystarczy, że jest wystawiony do sieci.

Jeśli nie masz pewności, czy i gdzie w Twojej organizacji działa PHP, to jest dobry moment, żeby to ustalić - niezależnie od tej konkretnej podatności. Inwentaryzacja tego, co masz wystawione do internetu, to pierwszy krok każdego sensownego podejścia do bezpieczeństwa.

Źródła

Opracowano na podstawie publikacji z 21 października 2026, m.in. php.net (wydania i komunikat zespołu PHP), NCSC UK, oraz analiz Patchstack, Help Net Security i Phoenix Security. Szczegóły, w tym dokładna punktacja CVSS, mogą być jeszcze aktualizowane.