Możesz mieć aktualnego WordPressa, mocne hasło i logowanie dwuetapowe, a mimo to nadal potrzebować pilnej poprawki bezpieczeństwa. Powodem są dwie krytyczne luki w PHP, określane jako PHP2Shell. To problem w oprogramowaniu działającym pod spodem strony.
21 października 2026 roku twórcy PHP opublikowali aktualizacje usuwające CVE-2026-109618 i CVE-2026-109619. Obie podatności otrzymały ocenę 9,2/10 w skali CVSS 4.0. Mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia. Dla właściciela strony oznacza to jedno: trzeba pilnie ustalić, czy hosting wdrożył poprawki. Komunikaty zespołu PHP.
W tej historii ważną rolę odegrała sztuczna inteligencja. Badacze Wiz wykorzystali modele AI do odkrywania podatności, analizy możliwości ich wykorzystania oraz weryfikacji poprawek. Błędy istniały w PHP od lat, ale AI pomogła przełożyć skomplikowane problemy z pamięcią na działające demonstracje ataku. Dla mnie to istotny sygnał: narzędzia pomagające znajdować i naprawiać luki mogą również skracać czas potrzebny do przygotowania ataków.
Co właściwie oznacza zdalne wykonanie kodu?
RCE, czyli Remote Code Execution, oznacza możliwość uruchomienia przez atakującego własnego kodu na podatnej maszynie. W tych lukach potwierdzono wykonanie kodu z uprawnieniami procesu obsługującego stronę. To istotne rozróżnienie: atak nie daje automatycznie pełnych uprawnień administratora całego serwera. Zakres szkód zależy od konfiguracji i dostępów tego procesu.
Możliwe konsekwencje obejmują odczyt dostępnych plików i sekretów aplikacji, a przy odpowiednich uprawnieniach także zmianę treści strony lub instalację złośliwego kodu. W WordPressie potencjalnym celem mogą być dane dostępowe do bazy zapisane w konfiguracji. To przykłady skutków wynikających z przejęcia procesu, a nie informacja, że doszło do nich na każdej stronie. Opis pierwszej podatności.
Z mojego punktu widzenia szczególnie groźna byłaby utrata kontroli nad tym, co widzi czytelnik. Na blogu finansowym podmieniony link lub fałszywy formularz potrafi wyrządzić więcej szkód niż sama przerwa w działaniu.
Na czym polegają obie luki?
CVE-2026-109618 dotyczy obsługi wyczerpania pamięci. PHP może przerwać operację, gdy część wewnętrznych danych nie została jeszcze w pełni przygotowana. Podczas końcowego porządkowania żądania nieprawidłowy stan pamięci może doprowadzić do wykonania kodu. Dla Apache z mod_php pokazano atak uruchamiany jeszcze przed wykonaniem kodu aplikacji.
CVE-2026-109619 dotyczy stanu pozostawionego między żądaniami. Proces PHP może zachować odwołanie do pamięci, która została już zwolniona. Kolejne żądanie obsługiwane przez ten sam proces może wykorzystać ten błędny stan. Opisano kilka wariantów zależnych między innymi od obsługi błędów i sesji. Opis drugiej podatności.
Czy każdą stronę na PHP można przejąć tak samo?
Nie. Zespół PHP obejmuje ostrzeżeniem instalacje obsługujące żądania WWW, w tym PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed. Jednocześnie sposób wykorzystania błędu zależy od środowiska. Najwyższe ryzyko wskazano dla mod_php. Nie należy przenosić szczegółów jednego demonstracyjnego ataku na wszystkie konfiguracje.
To jednak nie daje podstaw, żeby uznać PHP-FPM za bezpieczne. W dokumentacji drugiej luki potwierdzono również wariant RCE dla FPM, wymagający odpowiedniej operacji po stronie aplikacji. Konfiguracja zmienia warunki ataku, ale nie zastępuje aktualizacji.
Sama obecność podatnej wersji nie jest dowodem włamania. Tak samo poprawnie wyświetlająca się strona nie dowodzi, że wszystko jest w porządku.
Które wersje PHP zawierają poprawki?
Pierwsze oficjalne wydania z poprawkami opublikowane 21 października 2026 roku to:
| Gałąź PHP | Wydanie zawierające poprawki |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Ważne są wszystkie trzy części numeru. Samo „PHP 8.3” nie potwierdza obecności poprawki.
Jest też wyjątek: dostawcy dystrybucji i usług długiego wsparcia mogą przenieść poprawki do starszego pakietu bez zmiany jego podstawowego numeru na jeden z powyższych. Wtedy potrzebne jest potwierdzenie dostawcy dotyczące obu CVE. PHP 8.1 i starsze nie mają już standardowego wsparcia projektu; ewentualne poprawki dostawcy trzeba zweryfikować osobno.
Dlaczego aktualizacja WordPressa nie wystarczy?
WordPress, motyw i wtyczki to jedna warstwa. PHP zainstalowane na serwerze to kolejna. Kliknięcie aktualizacji w kokpicie WordPressa nie aktualizuje automatycznie interpretera PHP na hostingu.
Na hostingu zarządzanym poprawkę zwykle wdraża dostawca. Przy samodzielnie utrzymywanym VPS lub serwerze odpowiada za to administrator. Wordfence zaleca właścicielom stron sprawdzenie wersji PHP i ustalenie, kto wykona aktualizację. Wskazówki Wordfence dla właścicieli WordPressa.
Nie zakładałbym również, że wtyczka bezpieczeństwa załatwia sprawę. Wykazany wariant ataku może zadziałać, zanim WordPress zdąży się uruchomić.
Co zrobić teraz? Moja kolejność działania
- Sprawdź pełną wersję PHP. W WordPressie otwórz Narzędzia → Stan witryny → Informacje → Serwer. Odczytaj pole z wersją PHP.
- Uzyskaj potwierdzenie od hostingu. Zapytaj wprost o CVE-2026-109618 i CVE-2026-109619 oraz o PHP faktycznie obsługujące Twoją domenę. Ogólne zapewnienie, że serwery są monitorowane, nie odpowiada na to pytanie.
- Zabezpiecz kopię plików i bazy. Przed zmianami upewnij się, że masz aktualny backup i możliwość odtworzenia strony. Kopia pomaga odzyskać dane, ale sama nie blokuje ataku.
- Wdróż poprawione wydanie. Jeżeli używasz wspieranej gałęzi, poproś najpierw o jej aktualizację z poprawkami. Ewentualną migrację do innej gałęzi uzgodnij z administratorem i sprawdź zgodność motywu oraz wtyczek.
- Sprawdź stronę po wdrożeniu. Przetestuj logowanie, formularze, wysyłanie plików i najważniejsze funkcje. Potwierdź z administratorem, że działające procesy korzystają już z poprawionego PHP.
Sposób sprawdzenia wersji oraz zalecenia dotyczące kopii zapasowej i zgodności opisuje także oficjalny poradnik WordPressa. Przy tej konkretnej luce trzeba jednak kierować się pełnym numerem wydania i komunikatem bezpieczeństwa PHP, a nie samą ogólną rekomendacją gałęzi.
Do zgłoszenia u dostawcy przygotowałbym cztery pytania: czy usunięto obie podatności, jaki pakiet obsługuje moją domenę, kiedy wdrożono poprawkę i czy po aktualizacji odświeżono wszystkie procesy PHP. To pozwala ustalić stan konkretnej usługi.
Co, jeśli hosting jeszcze nie ma poprawki?
Zespół PHP opisuje ustawienia ograniczające niektóre ścieżki ataku, ale podkreśla, że nie ma kompletnego zamiennika aktualizacji. Nie traktowałbym przypadkowego wpisu w konfiguracji ani reguły zapory jako potwierdzenia usunięcia obu luk.
CERT-EU zaleca natychmiastowe poprawienie podatnych instalacji. Jeżeli nie jest to możliwe, rekomenduje rozważenie odizolowania publicznie dostępnych aplikacji do czasu wdrożenia i weryfikacji poprawki. Tę decyzję warto podjąć z administratorem, uwzględniając faktyczną ekspozycję i znaczenie usługi. Zalecenia CERT-EU.
Wtyczka pokazująca komunikat „przerwa techniczna” nadal wymaga uruchomienia PHP. Dlatego nie uznałbym jej za skuteczne odizolowanie podatnej usługi. Ograniczenie dostępu powinno nastąpić wcześniej, na poziomie infrastruktury.
A jeśli podejrzewasz włamanie?
Najpierw skontaktuj się z hostingiem lub administratorem i zabezpiecz logi oraz kopię obecnego stanu strony do analizy. Nie zaczynaj od masowego usuwania plików, bo możesz utrudnić ustalenie przyczyny.
Nieznane konta administratorów, nieautoryzowane zmiany plików, przekierowania czy ostrzeżenia o złośliwym kodzie wymagają sprawdzenia. Nie dowodzą jednak same w sobie wykorzystania PHP2Shell.
Usunięcie podatności i usunięcie skutków włamania to osobne zadania. Aktualizacja PHP nie skasuje wcześniej dodanego złośliwego kodu. Potrzebna może być odbudowa z zaufanych plików lub kopii, usunięcie nieautoryzowanych dostępów oraz zmiana ujawnionych haseł i sekretów. Takie postępowanie opisuje dokumentacja WordPressa dotycząca włamań.
Dlaczego potraktowałbym to priorytetowo?
Na blogu zwykle piszę o ryzyku związanym z inwestowaniem. Tutaj zasada jest podobna: najpierw ustalam, co mogę stracić i kto odpowiada za zabezpieczenie. Nie potrzebuję pewności, że ktoś już zaatakował moją stronę, żeby wdrożyć dostępną poprawkę krytycznej podatności.
Jeśli masz stronę na PHP, ustal dziś, czy jej środowisko otrzymało poprawki dla obu CVE. Najbardziej przydatna odpowiedź to konkretna wersja lub potwierdzenie załatanego pakietu obsługującego Twoją domenę.
