php2shell: dwie luki w PHP, przez które da się przejąć serwer bez logowania

O co chodzi

21 października 2026 projekt PHP wydał poprawki do dwóch krytycznych luk. Zestaw dostał nazwę php2shell. Numery to CVE-2026-109618 i CVE-2026-109619.

Obie siedzą w silniku PHP, nie w WordPressie, nie w Laravelu i nie w konkretnej wtyczce. Strona może być świeżo aktualizowana, a i tak jest podatna, jeśli pod spodem pracuje stara wersja PHP. Atakujący nie musi znać hasła do panelu. Wystarczy, że serwer przyjmuje zwykłe żądania HTTP.

26 października 2026 amerykańska agencja CISA wpisała obie luki na listę aktywnie wykorzystywanych. To nie jest teoretyczny opis. Ktoś już tego używa na żywych serwerach.

Z czym to się wiąże

PHP obsługuje żądanie odwiedzającego: składa dane z formularza, uruchamia kod strony i oddaje odpowiedź. Luki są w tej warstwie, wspólnej dla wszystkich aplikacji.

Dlatego dotyczy to naraz:

• WordPressa i WooCommerce,
• Laravel i własnych paneli,
• sklepów, formularzy i prostych stron na współdzielonym hostingu,
• kontenerów i obrazów, w których wersja PHP jest wbudowana na stałe.

Sposób uruchomienia też ma znaczenie. PHP może pracować jako moduł Apache (mod_php), jako osobne procesy PHP-FPM, jako CGI, FrankenPHP albo LiteSpeed. Fundacja PHP wskazuje Apache z mod_php jako wariant najwyższego ryzyka, bo pierwsza luka dała się tam pokazać przy domyślnych ustawieniach, zanim w ogóle wystartował kod aplikacji. Na PHP-FPM wykonanie kodu też zostało potwierdzone, tylko ścieżka idzie przez kod samej strony.

Skutek jest ograniczony do procesu PHP i uprawnień, z którymi ten proces chodzi. To i tak zwykle wystarcza, żeby czytać pliki strony, bazę, do której aplikacja ma dostęp, i zostawić na serwerze własny kod.

Jak działa pierwsza luka

CVE-2026-109618 dotyczy sytuacji, w której PHP w trakcie obsługi żądania kończy się pamięć.

Silnik w takim momencie ucieka z bieżącej roboty przez longjmp() i ma posprzątać żądanie. Problem w tym, że część wewnętrznych struktur żądania bywa wtedy dopiero w połowie złożona. Jak alokacja padnie w tym oknie, PHP nie domyka stanu. Później, przy sprzątaniu, czyta tę niedokończoną pamięć tak, jakby była prawidłowa, i podejmuje na niej decyzje.

Zużycie pamięci nie musi pochodzić z tej samej operacji, która zostawia strukturę niedokończoną. Da się je sprowokować samym żądaniem HTTP, jeszcze w parserze danych formularza, zanim aplikacja zobaczy treść. Stąd wykonanie kodu bez konta i bez błędu w motywie.

Jak działa druga luka

CVE-2026-109619 jest spokrewniona, ale idzie w drugą stronę: nie w głąb jednego żądania, tylko między żądaniami.

Proces PHP, zwłaszcza przy FPM i mod_php, obsługuje wielu odwiedzających po kolei. Po błędzie krytycznym we właściwym momencie proces zostawia u siebie wskaźnik do pamięci, która należała do poprzedniego żądania i została już zwolniona. Kolejne żądanie, które wpadnie do tego samego procesu, może z tej starej pamięci skorzystać.

Potwierdzono użycie zwolnionej pamięci i wywrócenie workera. Zgłaszający pokazał też wykonanie kodu na prawdziwej aplikacji pod Apache z mod_php.

Obie dziury leżą w zarządzaniu pamięcią i w obsłudze błędów. To fragmenty, przez które przechodzi prawie każde żądanie. Dlatego łatka musiała wejść w sam język, a nie w aktualizację jednej wtyczki.

Które wersje są dziurawe

Łatka jest tylko w tych wydaniach:

PHP od 5.4 do 8.1 nie dostało oficjalnej łatki pierwszej luki. Te gałęzie są poza wsparciem. Zostawienie ich w internecie oznacza, że dziura zostaje. Sensowna droga to przejście na wspieraną, poprawioną gałąź, nie kolejny „drobny” update w 8.1.

Sam numer w panelu hostingu to nie wszystko. Strona może chodzić na PHP 8.4 z panelu, a konsola i cron na starszej binarce. Po wgraniu łatki trzeba zrestartować procesy PHP (FPM albo Apache). Stary worker trzyma w pamięci dziurawy kod, dopóki nie wstanie od nowa.

Zapora aplikacji (WAF) może odsiać część prób w czasie, gdy łatka jeszcze schodzi na serwery. To nie zamyka luki. CISA wprost pisze, że systemy, których nie da się od razu podnieść, a szczególnie PHP 8.1 i starsze, powinny zejść z sieci do czasu aktualizacji.

Po czym poznać, że warto sprawdzić serwer od razu

• Hosting nie podaje wersji PHP nowszej niż 8.2.34, 8.3.35, 8.4.26 albo 8.5.11.
• Obraz Dockera albo paczka w systemie ma PHP sprzed 21 października 2026.
• W logach PHP widać procesy uruchamiające powłokę albo ściągające narzędzia, których strona normalnie nie używa.

Aktualizacja WordPressa, motywu i wtyczek tej dziury nie rusza. Rusza ją wyłącznie nowszy PHP i restart procesów, które go serwują.

Aktualizacje PHP robimy u nas

W Stronapp bierzemy aktualizacje PHP i to, co zwykle wychodzi przy okazji takiej łatki.

• Sprawdzenie, na jakiej wersji realnie stoi strona, konsola i zadania w tle.
• Podniesienie PHP na hostingu albo VPS do wydania z łatką i restart workerów.
• Przejście ze starych gałęzi 8.1 i niższych na wersję, która jeszcze dostaje poprawki.
• Test sklepu, formularzy, panelu i poczty po zmianie, żeby łatka nie wyłączyła sprzedaży.
• Opieka przy kolejnych wydaniach, zanim hosting podniesie PHP sam albo zostanie z dziurawą wersją.

Jak nie masz pewności, na czym stoi serwer, napisz do nas. Sprawdzimy wersję i przeprowadzimy aktualizację.