PHP2Shell: krytyczne luki w PHP a WordPress i serwer VPS

Aktualizacja: 30 października 2026. Artykuł obejmuje również informacje opublikowane po pierwotnej dacie wpisu.

21 października 2026 PHP otrzymało poprawki dwóch krytycznych luk umożliwiających zdalne wykonanie kodu. Atak nie wymaga logowania, a w niektórych konfiguracjach dochodzi do niego przed uruchomieniem kodu aplikacji. Problem dotyczy interpretera PHP, nie samego WordPressa.

Co się wydarzyło

20 października zespół PHP zapowiedział poprawki na następny dzień, z możliwością wcześniejszej publikacji w razie wycieku szczegółów. Poprawki wydano 21 października. Patchstack i Cloudflare informowały o próbach ataków jeszcze przed ich udostępnieniem. Publiczny kod demonstracyjny pojawił się w dniu wydania, a dostawcy zapór wprowadzili reguły ograniczające część zagrożeń.

Holenderskie serwisy rządowe, w tym DigiD i MijnOverheid, czasowo wyłączono prewencyjnie, a Uberspace wyłączył PHP na hostingu. Cloudflare udostępnił reguły również w planie darmowym, zaznaczając, że są środkiem tymczasowym.

Obie luki otrzymały ocenę 9,2 w skali CVSS 4.0: atak pochodzi z sieci i nie wymaga uwierzytelnienia ani udziału użytkownika, choć jego złożoność jest wysoka. Aktualizacja z 26 października: CISA dodała obie podatności do katalogu aktywnie wykorzystywanych luk, wyznaczając termin działań dla amerykańskich agencji federalnych na 29 października.

Dwie luki, różne mechanizmy

CVE-2026-109618 dotyczy uszkodzenia stanu podczas obsługi braku pamięci. Po przekroczeniu limitu pamięci PHP może przerwać żądanie w chwili, gdy jego dane nie są w pełni zainicjalizowane. Późniejsze sprzątanie może potraktować je jak poprawne. Wśród opisanych wektorów są nietypowe żądania z przesyłanymi plikami, licznymi nagłówkami lub zagnieżdżonymi nazwami pól. Brak pamięci może też wywołać samo żądanie do aplikacji.

CVE-2026-109619 dotyczy stanu globalnego procesu, który może wskazywać na zwolnioną pamięć po zakończeniu żądania. Następne działanie tego samego procesu może wykorzystać nieaktualny stan przed jego prawidłowym wyzerowaniem. Źródłem stanu może być między innymi błąd przetwarzania, przekroczenie czasu lub brak pamięci; jedną ze ścieżek wykorzystania jest funkcja śledzenia postępu wysyłania plików.

Znaczenie ma sposób uruchomienia PHP. W przypadku modułu Apache atak może wystąpić jeszcze przed wykonaniem aplikacji. PHP-FPM również jest uznawany za podatny, choć poszczególne ścieżki wykorzystania różnią się od przedstawionego scenariusza dla modułu Apache. Nie należy uznawać innej konfiguracji za bezpieczną tylko dlatego, że nie przedstawiono dla niej identycznego ataku.

Jakie jest zagrożenie

Wiz zademonstrował atak na obrazy WordPressa, Drupala i Joomli oraz prostą aplikację. Skutkiem może być wykonanie kodu z uprawnieniami konta procesu obsługującego stronę: dostęp do jej plików, bazy danych i danych uwierzytelniających. W niektórych scenariuszach możliwy jest również wyciek zawartości pamięci procesu.

Liczba żądań potrzebnych do wykorzystania zależy od konfiguracji i obranej ścieżki. Wysoka złożoność techniczna nie jest powodem do odkładania aktualizacji. Zagrożenie dla innych witryn na współdzielonym serwerze zależy także od izolacji kont i uprawnień.

Co zmienia poprawka

Poprawka zmienia obsługę wyczerpania pamięci. Miękki limit kończy żądanie w bezpieczniejszym miejscu, umożliwiając normalne czynności zamykające. Po przekroczeniu wyższego, twardego limitu proces kończy się natychmiast, bez uruchamiania funkcji zamykających i bez dokończenia buforowanej odpowiedzi.

Nowa dyrektywa memory_hard_limit_percent określa twardy próg względem limitu pamięci. Domyślny próg wynosi dwukrotność limitu dla wartości do 1 GB, a powyżej tej wartości limit powiększony o 1 GB. Ustawienie progu na 100 procent może powodować natychmiastowe zakończenie procesu przy wyczerpaniu pamięci. Brak limitu pamięci wyłącza również próg obliczany na jego podstawie.

Poprawka czyści także szerszy stan globalny. Natychmiastowe zakończenie procesu może jednak uniemożliwić zapis części informacji diagnostycznych lub dokończenie obsługi żądania. Kod wyjścia 137 może towarzyszyć takiemu zakończeniu, ale sam nie dowodzi ani ataku, ani jego braku.

Wersje PHP i wsparcie

Wydania projektu PHP zawierające poprawki to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wydanie 8.6.0 RC4 również je zawiera, ale jest kandydatem do wydania, a nie zalecaną wersją produkcyjną. Wsparcie PHP 8.2 kończy się 31 grudnia 2026, a 8.3 — 31 grudnia 2027.

Projekt udostępnił minimalne poprawki źródłowe dla wycofanych gałęzi 7.4, 8.0 i 8.1. Wyłączają one funkcję śledzenia postępu wysyłania plików i nie dodają nowego twardego limitu pamięci. Nie oznacza to przywrócenia regularnego wsparcia. Dostawcy systemów i hostingu mogą oferować własne poprawione pakiety dla innych wersji.

Co powinien zrobić właściciel WordPressa

Nie szukaj osobnej łatki do WordPressa jako rozwiązania tego problemu. Trzeba poprawić interpreter PHP. W panelu WordPressa wersję można sprawdzić w części Narzędzia → Stan witryny → Informacje → Serwer; wiele hostingów pokazuje ją także w swoim panelu.

Na hostingu współdzielonym zapytaj dostawcę o poprawkę dla używanej wersji i konkretnego serwera. Sam numer wersji nie zawsze rozstrzyga sprawę, ponieważ dostawca może przenieść poprawkę do starszego pakietu. OVH poinformował o wdrożeniu własnych poprawek także dla starszych wersji; inni dostawcy mogą mieć inny harmonogram.

Wtyczka bezpieczeństwa nie naprawia interpretera. Zapora może ograniczać wybrane żądania, ale chroni tylko ruch, który faktycznie przez nią przechodzi, i nie zastępuje aktualizacji.

Aktualizacja i weryfikacja VPS

Administrator powinien zinwentaryzować wszystkie wersje i sposoby uruchamiania PHP: pule PHP-FPM, moduł Apache, PHP CGI, LiteSpeed, FrankenPHP, kontenery, procesy kolejek i osobne środowisko panelu. Nie wystarczy sprawdzić wersji domyślnej, jeśli inne witryny korzystają z innych pakietów.

Po aktualizacji postępuj zgodnie z instrukcjami dostawcy dotyczącymi uruchomienia nowych procesów. Biuletyny zalecają restart wszystkich procesów roboczych po zmianach zabezpieczających; samo przeładowanie konfiguracji nie jest wskazywane jako wystarczające. Restart usług na serwerze współdzielonym zaplanuj z uwzględnieniem wszystkich obsługiwanych witryn.

Weryfikuj stan w biuletynie bezpieczeństwa i historii konkretnego pakietu dystrybucji. Sama wersja wyświetlana przez interpreter może nie ujawniać przeniesionej poprawki. Obecność nowej dyrektywy może być pomocną wskazówką w wydaniach, które ją zawierają, ale nie należy traktować jej braku jako rozstrzygającego testu wszystkich poprawek dostawców, zwłaszcza minimalnych poprawek starszych gałęzi.

Pakiety różnych dostawców

Numeracja pakietów bywa niższa niż numer poprawionego wydania projektu PHP. Przykładowo AlmaLinux publikował poprawki dla swoich gałęzi 8.2, 8.3 i 8.4 z zachowaniem numeracji pakietów dystrybucji. Ubuntu i Debian również identyfikują poprawki przez wersję pakietu i właściwy biuletyn bezpieczeństwa.

W dostarczonym zestawieniu wskazano między innymi Debian 13 z pakietem 8.4.27-1~deb13u1 oraz Debian 12 z pakietem 8.2.35-1~deb12u1. Sprawdzaj aktualny komunikat dla konkretnego systemu, repozytorium i architektury. Pakiety dla różnych architektur mogą pojawić się w innym czasie.

CloudLinux ostrzegał, że brak metadanych aktualizacji bezpieczeństwa może sprawić, iż filtr aktualizacji ograniczony do poprawek bezpieczeństwa pominie pakiet. W cPanelu pakiety EasyApache 4 są odrębną sprawą od PHP używanego przez sam panel. Starsze gałęzie mogą nie mieć poprawki u każdego dostawcy.

Środki tymczasowe i ich ograniczenia

Tylko aktualizacja usuwa zagrożenie u źródła. Jeśli nie da się jej wdrożyć od razu, zalecenia projektu PHP przewidują środki ograniczające wybrane ścieżki, ale nie gwarantują pełnej ochrony.

• W przypadku CVE-2026-109618 czasowe wyłączenie limitu pamięci PHP utrudnia wymuszenie konkretnej ścieżki błędu. Usuwa jednak ochronę przed nadmiernym zużyciem pamięci i wymaga odpowiedniej zewnętrznej granicy zasobów, na przykład dla kontenera lub grupy procesów. Błąd rzeczywistej alokacji nadal może wystąpić.
• Nie zastępuj tej granicy limitami RLIMIT_AS ani RLIMIT_DATA: błąd alokacji może uruchomić podatną ścieżkę.
• Ogranicz rozmiar i strukturę żądań stosownie do potrzeb aplikacji, uwzględniając również żądania bez użytecznej informacji o długości. Przykładowe limity opisane przez projekt PHP to 8 MB bez wysyłania plików i 32 MB, gdy jest ono potrzebne; mogą wymagać dostosowania do witryny.
• Dla CVE-2026-109619 wyłączenie funkcji śledzenia postępu wysyłania plików oraz ponowne uruchomienie procesów ogranicza wskazaną ścieżkę. W PHP 8.5 wyłączenie funkcji śladów błędów krytycznych ogranicza inną potwierdzoną ścieżkę. Nie są to zabezpieczenia wszystkich możliwych wariantów.

Ustawienia muszą obowiązywać przed rozpoczęciem przetwarzania żądania; zmiana z poziomu aplikacji może nastąpić zbyt późno. Wyłączenie śledzenia postępu może usunąć paski postępu w formularzach. Ukrywanie komunikatów o błędach nie usuwa przyczyny. Przy każdej zmianie należy ocenić wpływ na dostępność i stosować oficjalny biuletyn dla danej wersji.

23 października PHP opublikowało także informacyjne doradztwo dotyczące CVE-2026-115560 w tym samym obszarze. Dotyczy ono szczególnej konfiguracji zmienianej podczas działania aplikacji. Zalecenia dotyczące wyłączenia funkcji należy oceniać osobno dla obu podatności i aktualnego stanu poprawek.

Możliwe ślady ataku

Sygnałami mogą być nietypowe żądania zawierające dane formularzy, powtarzające się błędy pamięci lub odpowiedzi HTTP 500, nietypowe ciasteczka sesyjne i niewyjaśnione zakończenia procesów PHP. Żaden z tych objawów sam w sobie nie dowodzi włamania.

Brak śladów w dzienniku WordPressa nie wyklucza ataku poniżej warstwy aplikacji. W razie podejrzenia naruszenia zabezpieczeń potraktuj serwer jako potencjalnie przejęty, zabezpiecz dane do analizy i zaplanuj zmianę poświadczeń, w tym haseł do bazy oraz kluczy usług.

Kolejność działań

1. Ustal wszystkie środowiska obsługujące żądania PHP i ich dostawców.
2. Sprawdź dostępność poprawek dla konkretnych pakietów, także w kontenerach i panelach.
3. Wdróż poprawki i uruchom ponownie odpowiednie procesy zgodnie z zaleceniami dostawcy.
4. Potwierdź wersję pakietu i status poprawki w biuletynie. Na hostingu współdzielonym uzyskaj potwierdzenie od dostawcy.
5. Środki tymczasowe stosuj tylko wtedy, gdy aktualizacja jest niemożliwa, ze świadomością skutków dla pamięci i funkcji witryny.

Źródła: komunikat CISA, biuletyn PHP dotyczący CVE-2026-109618 oraz biuletyn PHP dotyczący CVE-2026-109619.

Najczęstsze pytania

Czy luka dotyczy samego WordPressa?

Nie, podatności dotyczą interpretera PHP, na którym działa WordPress. Aktualizację PHP powinien wdrożyć administrator serwera lub dostawca hostingu.

Czy atakujący musi mieć konto na stronie?

Nie, obie podatności mogą prowadzić do wykonania kodu bez uwierzytelnienia. Możliwość wykorzystania zależy jednak od konfiguracji i ścieżki ataku.

Czy sam numer wersji PHP potwierdza obecność poprawki?

Nie zawsze. Dostawca systemu może przenieść poprawkę do starszego wydania pakietu, zachowując jego numer bazowy. Sprawdź biuletyn i wersję pakietu dostawcy.

Czy zapora zastępuje aktualizację PHP?

Nie. Zapora może ograniczyć wybrane ścieżki ataku, ale nie zapewnia pełnej ochrony. Aktualizacja pozostaje podstawowym rozwiązaniem.

Czy trzeba sprawdzić każdą wersję PHP na serwerze?

Tak, należy zinwentaryzować wszystkie używane wersje i sposoby uruchamiania PHP. Dotyczy to również kontenerów i usług panelu, jeśli obsługują żądania.

Czy poprawki obejmują niewspierane wersje PHP?

Projekt PHP udostępnił minimalne poprawki źródłowe dla wybranych starszych gałęzi. Nie przywraca to ich standardowego wsparcia, a dostępność pakietów zależy od dostawcy.

Co oznacza kod wyjścia 137 procesu PHP?

Może towarzyszyć zadziałaniu nowego twardego limitu pamięci, ale sam kod nie rozstrzyga przyczyny. Należy sprawdzić komunikaty i inne zdarzenia systemowe.

Czy wyłączenie limitu pamięci jest bezpieczną poprawką?

Nie. Jest to wyłącznie tymczasowe ograniczenie jednej ścieżki ataku i osłabia ochronę przed wyczerpaniem pamięci. Wymaga odpowiedniej zewnętrznej granicy zasobów.

Czy wyłączenie śledzenia wysyłania plików ma skutki uboczne?

Tak, może przestać działać pasek postępu w formularzach i wtyczkach korzystających z tej funkcji. Zakres skutków zależy od aplikacji.

Czy brak błędów w dzienniku WordPressa wyklucza atak?

Nie. Podatności występują poniżej warstwy WordPressa, więc jego dzienniki mogą nie zawierać śladów. Podejrzane zdarzenia trzeba analizować również na poziomie serwera.