Luka bezpieczeństwa PHP2Shell w WordPress: co muszą zrobić administratorzy

Krótko: Luka bezpieczeństwa PHP w WordPress, o której obecnie się mówi, nie tkwi w WordPressie, lecz w PHP na serwerze pod spodem. Aktualizacja WordPressa nie zamyka więc PHP2Shell. Rozstrzygające są stan poprawek PHP, restart wszystkich procesów PHP oraz kontrola typowych kryjówek, takich jak wp-content/uploads i mu-plugins.

Dlaczego aktualizacja WordPressa nie usuwa PHP2Shell

WordPress to aplikacja napisana w PHP. Luki CVE-2026-109618 i CVE-2026-109619 leżą poziom niżej, w samym interpreterze PHP. Według zespołu PHP umożliwiają zdalne wykonanie złośliwego kodu bez logowania. W przypadku Apache z mod_php pokazano exploit, zanim w ogóle zacznie działać kod WordPressa.

Strona z aktualnym rdzeniem, aktualnymi wtyczkami i silnymi hasłami może więc nadal być podatna na atak, jeśli PHP pod spodem jest stare. I odwrotnie: załatane PHP nie dowodzi, że wcześniej nic się nie stało. Tło wyjaśniamy w artykule Czym jest PHP2Shell?.

Luka bezpieczeństwa PHP w WordPress: sprawdzanie wersji PHP

W panelu administracyjnym w sekcji Narzędzia > Kondycja witryny > Informacje w części „Serwer” znajdą Państwo wersję PHP, na której Państwa strona faktycznie działa. To bardziej wiarygodne niż php -v w wierszu poleceń, ponieważ wiersz poleceń często używa innej instalacji PHP niż serwer WWW.

Sam wyświetlany numer jednak nie wystarcza. Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wiele firm hostingowych wprowadza jednak poprawki jako backport; wtedy nadal widnieje starszy numer, choć system jest załatany. Jak ustalić rzeczywisty stan, opisujemy w artykule Jak prawidłowo sprawdzić wersję PHP i stan poprawek. To, które wersje PHP obsługuje Państwa wersja WordPressa, można sprawdzić w wymaganiach systemowych na wordpress.org.

Gdzie w WordPressie chętnie ukrywa się złośliwy kod

Po udanym ataku sprawcy zwykle zostawiają tylne drzwi, aby wrócić także po zainstalowaniu poprawki. WordPress ma do tego znane miejsca:

• wp-content/uploads/: przeznaczony na obrazy i pliki PDF, nie na pliki PHP.
• wp-content/mu-plugins/: wtyczki „must-use” ładują się automatycznie i nie można ich wyłączyć w panelu administracyjnym.
• wp-config.php: zawiera dane dostępowe do bazy danych i klucze bezpieczeństwa; dopisana linia jest tu prawie niezauważalna.
• .htaccess w katalogu głównym i w podfolderach: przekierowania tylko dla wyszukiwarek lub wykonywanie nietypowych rozszerzeń plików.
• Motywy, zwłaszcza functions.php, oraz wyłączone, zapomniane wtyczki.
• Baza danych: nowi administratorzy w wp_users, obcy kod JavaScript w wp_options lub we wpisach.

Bezpieczne pierwsze kontrole za pomocą WP-CLI i wbudowanych narzędzi:

# Porównanie plików rdzenia z oficjalnymi sumami kontrolnymi
wp core verify-checksums
# Sprawdzenie wtyczek z katalogu na wordpress.org
wp plugin verify-checksums --all
# Wypisanie plików PHP w folderze uploads
find wp-content/uploads -type f -name "*.php"
# Wyświetlenie wszystkich administratorów
wp user list --role=administrator

Trafienie to powód do dokładnego zbadania sprawy, a jeszcze nie dowód. Wtyczek komercyjnych nie da się w ten sposób sprawdzić. Szczegóły znajdą Państwo w poradniku Wyszukiwanie backdoorów w WordPressie.

Wtyczki, motywy i dostępy administratora jako dodatkowe ryzyko

PHP2Shell nie potrzebuje luki we wtyczce. W codziennej pracy wtyczki i motywy pozostają jednak najczęstszym punktem wejścia na strony WordPress. Każda wtyczka wnosi własny kod, własne funkcje przesyłania plików i własne cykle aktualizacji. Nieużywane wtyczki należy usuwać, a nie tylko wyłączać, ponieważ wyłączone pliki nadal leżą na serwerze.

Dla wp-login.php i wp-admin obowiązuje: niewielu administratorów, konta osobiste zamiast wspólnych dostępów i uwierzytelnianie dwuskładnikowe. Jeśli XML-RPC nie jest potrzebny, można go zablokować. W razie podejrzenia należy zmienić wszystkie hasła i klucze bezpieczeństwa w wp-config.php. Edytor plików w panelu administracyjnym wyłącza się również tam:

define( 'DISALLOW_FILE_EDIT', true );

Co powinni teraz zrobić administratorzy WordPressa

1. Poprosić firmę hostingową o pisemne potwierdzenie stanu poprawek PHP i restartu wszystkich procesów PHP.
2. Zlecić zachowanie logów serwera od 20.10.2026.
3. Przeprowadzić powyższe kontrole lub zlecić ich przeprowadzenie.
4. Zaktualizować WordPressa, wtyczki i motywy. To słuszne, ale nie zastępuje kroku 1.
5. W razie nieprawidłowości nie prowadzić strony po prostu dalej, lecz zlecić jej oczyszczenie.

Aktualizacja platformy może zamknąć znane luki w WordPressie i wtyczkach. Nie naprawi jednak PHP ani nie usunie wprowadzonych plików, które nie należą do rdzenia.

Jak konkretnie pomaga PHP SOS?

• Ustalamy z Państwem lub Państwa firmą hostingową rzeczywisty stan PHP Państwa strony WordPress, wraz z backportami i restartem.
• Zabezpieczamy logi, pliki i bazę danych, zanim cokolwiek zostanie zmienione.
• Sprawdzamy rdzeń, wtyczki, uploads, mu-plugins, .htaccess i konta użytkowników pod kątem tylnych drzwi.
• W razie znalezisk oczyszczanie przejmuje nasza usługa usuwania złośliwego oprogramowania aż do zamknięcia i udokumentowania incydentu; jeśli niczego nie znajdziemy, utwardzamy instalację w ramach natychmiastowej pomocy przy PHP2Shell.

Częste pytania

Źródła

• php.net: komunikaty bezpieczeństwa
• PHP 8 ChangeLog
• WordPress.org
• BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej)