Czy aktualizacja WordPressa albo Joomli usuwa wirusa? Co naprawdę robi reinstalacja

Po wykryciu infekcji wielu właścicieli stron robi jedno: klika „Aktualizuj WordPress” albo wgrywa najnowszą Joomlę po starej. Strona dostaje nowy numer wersji, panel pokazuje zieloną kropkę, a tydzień później hosting znów pisze o malware. Aktualizacja nie usunęła infekcji, bo nigdy nie miała tego zrobić.

Co nadpisuje aktualizacja

Aktualizacja rdzenia podmienia pliki, które należą do CMS‑a: w WordPressie wp-admin/, wp-includes/ i pliki w katalogu głównym poza wp-config.php; w Joomli administrator/, libraries/, components/, plugins/ systemowe i tak dalej. Jeśli infekcja doklejała kod do tych plików, aktualizacja ją usunie, ale tylko z nich.

Przy czym nadpisuje pliki, które są w paczce. Plik, który atakujący dodał pod własną nazwą do wp-includes/ (np. wp-includes/class-wp-cache-helper.php), nie jest w paczce, więc zostaje. Aktualizacja go nie zna, nie kasuje, nie zgłasza.

Czego aktualizacja nie dotyka

Lista jest długa i to właśnie w niej żyje większość infekcji:

• wp-content/ w całości: motywy, wtyczki, uploads/, mu-plugins/, cache;
• w Joomli: images/, media/, templates/, tmp/, cache/, rozszerzenia firm trzecich;
• wp-config.php i configuration.php — tam atakujący dopisuje include na swój plik;
• .htaccess w katalogu głównym i w podkatalogach;
• pliki w katalogu głównym o obcych nazwach (about.php, radio.php, xmlrpc2.php);
• baza danych w całości;
• zaplanowane zadania systemowe (cron) na koncie hostingowym, jeśli atakujący miał dostęp do SSH;
• hasła, klucze API, sole, sesje.

W praktyce: po aktualizacji atakujący ma nadal działający web‑shell w uploads/, nadal działającą wtyczkę w mu-plugins/, nadal swoje konto administratora i nadal hasło do FTP, które wyciekło na początku. Jedyne, co się zmieniło, to numer wersji.

Czy aktualizacja jest więc bez sensu?

Nie. Aktualizacja zamyka lukę, przez którą infekcja weszła, jeśli luka była w rdzeniu. Jest konieczna, ale jako jeden z ostatnich kroków, nie pierwszy. Kolejność ma znaczenie:

1. Kopia plików i bazy, zanim cokolwiek się zmieni.
2. Usunięcie infekcji: porównanie z wydaniem, kwarantanna obcych plików, przegląd bazy, czyszczenie .htaccess.
3. Zmiana haseł, soli, kluczy; usunięcie obcych kont; unieważnienie sesji.
4. Dopiero teraz aktualizacja rdzenia, motywu i wszystkich wtyczek. Usunięcie wtyczek nieużywanych, nie tylko wyłączenie.
5. Kontrola po naprawie i monitoring przez kilka tygodni.

Jeśli zrobisz aktualizację jako pierwszy krok, nadpiszesz dowody (daty modyfikacji plików rdzenia, które pokazywały, kiedy atak się zaczął) i utrudnisz sobie ustalenie drogi wejścia.

A reinstalacja „od zera”?

Reinstalacja z czystych plików, z zachowaniem własnego motywu, wtyczek, uploads/ i bazy, ma te same ograniczenia co aktualizacja. Zostawiasz wszystko, w czym infekcja najczęściej siedzi.

Reinstalacja naprawdę od zera (nowa instalacja, nowa baza, ręczne przeniesienie tylko treści) usuwa infekcję, ale kosztuje dni pracy, a przy sklepie z zamówieniami i klientami bywa nierealna. Dla większości stron rozsądniej jest wyczyścić to, co jest, metodycznie, z kwarantanną, i zostawić ślad każdej zmiany.

Porównanie z wydaniem zamiast aktualizacji

Jest trzecia droga, która łączy zalety obu: porównanie każdego pliku rdzenia z oficjalnym wydaniem tej samej wersji. Plik identyczny jest czysty. Plik różny jest podejrzany i zostaje zastąpiony oryginałem, a zainfekowana wersja idzie do kwarantanny. Plik, którego w wydaniu nie ma, jest obcy i trafia do analizy. To rozstrzyga rdzeń bez zgadywania i bez zmiany wersji, więc strona działa jak przed naprawą. Na tym opiera się pierwsza warstwa skanu w CleanOps.

Aktualizację zrób potem. Z czystej strony na nową wersję przechodzi się bez niespodzianek.