Krótko: Backdoor w WordPressie najszybciej znajdą Państwo, porównując rdzeń i wtyczki za pomocą WP-CLI z oficjalnymi sumami kontrolnymi, a następnie celowo przeglądając mu-plugins, uploady, wp-config.php, konta administratorów i bazę danych. Ważne po PHP2Shell: aktualizacja WordPressa nie zamyka luki w PHP i nie usuwa istniejącej tylnej furtki.
Dlaczego operatorzy WordPressa powinni teraz przyjrzeć się dokładniej
Wraz z PHP2Shell w październiku 2026 ujawniono dwie krytyczne luki w samym PHP, CVE-2026-109618 i CVE-2026-109619. Umożliwiają wykonanie złośliwego kodu bez logowania, niezależnie od tego, jak dobrze utrzymana jest Państwa instalacja WordPressa. Poprawki są dostępne od 21.10.2026, ale według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17.10.
Kto w tym okresie był podatny, powinien szukać śladów. WordPress jest typowym celem, ponieważ wiele instalacji jest zbudowanych podobnie, a atakujący znają kryjówki. Co operatorzy muszą zrobić w związku z PHP2Shell ogólnie, opisuje strona WordPress i PHP2Shell.
Poniższe kontrole proszę wykonać możliwie na kopii lub po wykonaniu kopii zapasowej. Polecenia tylko odczytują i niczego nie zmieniają.
Po czym na co dzień można zauważyć backdoor
Tylna furtka jest zaprojektowana tak, by pozostać niezauważona. Mimo to istnieją oznaki, które zauważy się nawet bez wiedzy technicznej. Należą do nich przekierowania na obce strony, które występują tylko u odwiedzających z wyszukiwarki Google lub tylko na urządzeniach mobilnych. Podejrzane są też nowe strony z reklamami leków, hazardu lub kopii produktów markowych, które pojawiają się w indeksie wyszukiwarki, ale nie w panelu WordPressa.
Dalsze wskazówki to ostrzeżenia od Google lub przeglądarki, skargi klientów na spam wysyłany z Państwa domeny, nagle mocno zwiększone zużycie mocy obliczeniowej u dostawcy hostingu albo administratorzy, których nikt w zespole nie zna. Żadna z tych oznak sama nie dowodzi backdoora. Jeśli występuje ich kilka naraz, nie powinni Państwo odkładać poniższych kontroli.
Odwrotnie: jeśli nic z tego nie zwraca uwagi, nie znaczy to, że instalacja jest czysta. Zwłaszcza tylne furtki założone wyłącznie na potrzeby późniejszego dostępu często nie dają na zewnątrz żadnego efektu.
Jak znaleźć backdoor w WordPressie: sprawdzanie rdzenia i wtyczek
WP-CLI potrafi porównać pliki rdzenia WordPressa i wtyczek z oficjalnego katalogu z opublikowanymi sumami kontrolnymi. Każde odchylenie to konkretne zadanie kontrolne.
cd /var/www/meine-seite
# Pliki rdzenia względem oficjalnych sum kontrolnych
wp core verify-checksums
# Wtyczki z oficjalnego katalogu
wp plugin verify-checksums --all
# Zainstalowane wersje i status
wp plugin list
wp theme list
Komercyjnych wtyczek i motywów nie da się w ten sposób sprawdzić. Dla nich pomaga tylko porównanie ze świeżo pobranym oryginalnym pakietem dostawcy. Nieznane wtyczki, których nikt w zespole nie zainstalował, są zawsze podejrzane, nawet jeśli wyglądają na wyłączone.
Typowe kryjówki w systemie plików
Niektóre miejsca powtarzają się w skompromitowanych instalacjach WordPressa:
wp-content/mu-plugins/: ładowany automatycznie i niewidoczny na zwykłej liście wtyczek.wp-content/uploads/: tam należą obrazy i dokumenty, a nie pliki PHP.wp-config.php: dodatkowe wierszeincludelubrequirena początku lub na końcu..htaccessi.user.iniw katalogu WWW i podfolderach: nieoczekiwane przekierowania lub automatycznie wstępnie ładowane pliki.- Pliki w katalogu głównym, których nazwy przypominają pliki rdzenia WordPressa, ale do niego nie należą.
# Pliki PHP w folderze uploadu
find wp-content/uploads -type f -name "*.php*"
# Zawartość wtyczek Must-Use
ls -la wp-content/mu-plugins/
# Wszystkie pliki .htaccess i .user.ini z datą zmiany
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Ostatnio zmienione pliki PHP
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Ogólne wzorce wyszukiwania zaciemnionego kodu opisuje poradnik Jak wykryć i usunąć webshell.
Sprawdzanie użytkowników, bazy danych i zaplanowanych zadań
Wiele tylnych furtek wcale nie leży w systemie plików. Dodatkowe konto administratora często wystarcza atakującym, by później wrócić.
# Wszyscy administratorzy z datą rejestracji
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Zaplanowane zadania w WordPressie
wp cron event list
# Adres strony (manipulacje prowadzą do przekierowań)
wp option get siteurl
wp option get home
# Wpisy z osadzonymi skryptami
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Proszę sprawdzić także opcje o nietypowo dużej zawartości i widżety z obcym kodem. Trafienia nie oznaczają automatycznie ataku, ponieważ kody śledzące czy osadzone mapy również używają skryptów. Rozstrzygające jest, czy ktoś w zespole zna tę zawartość.
Po znalezisku proszę zmienić wszystkie hasła i klucze bezpieczeństwa w wp-config.php. W przeciwnym razie istniejące logowania atakujących pozostaną ważne.
Zamykanie tylnych furtek i zapobieganie powrotowi
Jeśli znaleźli Państwo backdoor, nowa instalacja jest zwykle bezpieczniejsza niż naprawianie pojedynczych plików. Sprawdziła się ta kolejność:
- Zabezpieczyć ślady: zapisać z datą logi, podejrzane pliki i eksport bazy danych.
- Doprowadzić PHP do naprawionego stanu i zrestartować wszystkie procesy PHP.
- Zainstalować rdzeń WordPressa, wtyczki i motywy od nowa z oryginalnych źródeł.
- Przejąć sprawdzone uploady i bazę danych, usunąć obce konta, zmienić wszystkie dostępy.
- Zablokować wykonywanie PHP w folderze uploadu na poziomie serwera.
Dla Nginx wystarczy do tego blok w konfiguracji serwera:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
W Apache osiągną Państwo to samo regułą w konfiguracji serwera dla folderu uploadu. Plik .htaccess w samym folderze uploadu jest słabszy, ponieważ atakujący z prawami zapisu może go ponownie zmienić.
Po oczyszczeniu proszę zaplanować na kilka tygodni ściślejszą obserwację. Nowi administratorzy, nowe pliki PHP i zmiany w wp-config.php powinny w tym czasie od razu rzucać się w oczy, na przykład dzięki regularnej kontroli za pomocą WP-CLI lub monitorowaniu plików na serwerze.
Jak następnie ustawić uprawnienia do plików tak, by WordPress mógł zapisywać tylko tam, gdzie to konieczne, pokazuje poradnik Uprawnienia do plików na serwerze WWW.
Jak konkretnie pomaga PHP SOS?
- Zabezpieczamy stan instalacji, zanim cokolwiek zostanie zmienione.
- Sprawdzamy rdzeń, wtyczki, motywy, bazę danych, konta i konfigurację serwera pod kątem tylnych furtek.
- Stawiamy WordPressa od nowa z czystych źródeł i przejmujemy tylko sprawdzone zawartości.
- Utwardzamy serwer i instalację oraz dokumentujemy, co znaleziono i naprawiono.
Przebieg oczyszczania opisuje usługa Usuwanie malware i webshelli.
Częste pytania
Czy aktualizacja WordPressa zamyka lukę PHP2Shell?
Nie. PHP2Shell tkwi w interpreterze PHP, a nie w WordPressie. Aktualizacja WordPressa, motywów lub wtyczek niczego tu nie zmienia; decydujący jest stan PHP serwera i restart wszystkich procesów PHP.
Czy wtyczka bezpieczeństwa znajdzie wszystkie backdoory?
Nie w sposób niezawodny. Wtyczka działa wewnątrz skompromitowanej instalacji i sama może zostać zmanipulowana. Proszę uzupełnić ją o kontrole z zewnątrz, na przykład sumy kontrolne WP-CLI i porównanie z czystymi plikami oryginalnymi.
Czym są mu-plugins i dlaczego budzą podejrzenia?
Wtyczki Must-Use w folderze wp-content/mu-plugins ładują się automatycznie i nie pojawiają się na zwykłej liście wtyczek. Atakujący chętnie to wykorzystują, ponieważ administratorzy rzadko zaglądają do tego folderu.
Czy backdoor może tkwić także w bazie danych?
Tak. Złośliwy kod lub przekierowania często umieszcza się w opcjach, wpisach lub widżetach. Dodatkowo atakujący często zakładają własne konta administratorów, które można znaleźć w tabeli użytkowników.