WordPress i backdoor, który sam się odbudowuje po usunięciu
Sucuri opisuje backdoor WordPressa, który sam się odbudowuje po usunięciu
Na przełomie września i października 2026 roku badacze bezpieczeństwa z Sucuri opublikowali analizę kampanii złośliwego oprogramowania nazwanej SC — od znacznika „SC_” widocznego we wstrzykiwanym kodzie. To nie jest opis kolejnej pojedynczej podatności w jednej wtyczce. To opis tego, jak atakujący utrzymują dostęp do zainfekowanej witryny WordPress długo po tym, jak administrator uznał, że problem został rozwiązany.
Mechanizm jest prosty do opisania i trudny do usunięcia w praktyce. Złośliwy kod nie leży w jednym miejscu, tylko w co najmniej ośmiu miejscach jednocześnie. Wśród nich: plik .user.ini, ukryte loadery PHP, zmodyfikowany drop-in WordPressa typu advanced-cache.php, zmienione pliki motywu, dodatkowa wtyczka typu „must-use” i kopia zwykłej wtyczki. Do tego dochodzi wiersz w tabeli wp_options w bazie danych, zawierający spakowaną kopię całego payloadu, oraz segment pamięci dzielonej System V, który żyje w RAM serwera i przetrwa zarówno usunięcie plików, jak i czyszczenie bazy — a na hostingu współdzielonym może być nawet przypisany do innego konta niż konto ofiary. Każdy z tych elementów potrafi odtworzyć pozostałe. Usunięcie jednego pliku nie kończy infekcji, bo pozostałe miejsca po prostu go odtwarzają, często przy najbliższym wywołaniu zadania cron zarejestrowanego pod losową nazwą.
Dla kogoś, kto samodzielnie administruje witryną, to zmienia definicję „wyczyszczonej” strony. Ręczne usunięcie podejrzanego pliku przez FTP albo wtyczka bezpieczeństwa, która znajdzie jeden loader, nie daje żadnej gwarancji. Realne czyszczenie wymaga porównania całego katalogu z czystym źródłem — jądrem WordPressa, motywem i wtyczkami — przeglądu tabeli wp_options pod kątem nietypowych wpisów i sprawdzenia zarejestrowanych zadań cron. Przy poważnej infekcji jedynym pewnym rozwiązaniem bywa odbudowa środowiska od zera z kopii zapasowej sprzed infekcji, a nie łatanie tego, co już jest zainfekowane.
Badacze zwracają też uwagę, że publikacja ich analizy zbiegła się w czasie z aktywnym wykorzystywaniem podatności SQL injection w wtyczce wpForo Forum (CVE-2026-1581). Czy to jeden z wektorów wejścia dla kampanii SC, czy tylko zbieg czasowy — to jeszcze niejasne, raporty nie łączą tych dwóch spraw jednoznacznie.
Z perspektywy kogoś, kto mierzy TTFB i przechodzi testy obciążeniowe na co dzień, to dobre przypomnienie, że szybki serwer nie zastąpi dobrze zabezpieczonej instalacji WordPressa. Metodologię naszych pomiarów opisaliśmy na stronie jak liczymy, a metodologię audytów technicznych — na stronie jak testujemy. Pełne wyniki testowanych hostingów są w rankingu.
