Case study
Ratowanie WordPressa po infekcji i usunięcie błędów 504
Oczyściliśmy zainfekowany portal WordPress, odtworzyliśmy czysty rdzeń, podnieśliśmy PHP i MySQL, wymusiliśmy HTTPS oraz usunęliśmy źródło przeciążeń powodujących błędy 504.
Podsumowanie
Zainfekowany i przeciążony portal WordPress został oczyszczony, odtworzony na czystym rdzeniu i przeniesiony na aktualne środowisko. Zakres objął WordPress 7, PHP 8.5, MySQL 8, Apache, HTTPS, rotację dostępów i usunięcie przyczyny błędów 504.
Sytuacja wyjściowa
Portal działał na WordPressie 6.2.2, PHP 8.0 i MySQL 5.7. Malware znajdowało się także w plikach systemowych i na poziomie całego konta hostingowego. Serwer był przeciążony, użytkownicy trafiali na błędy 504, a część aktualizacji i zabezpieczeń pozostawała nieaktualna.
Problem biznesowy
Podmiot publiczny potrzebował wiarygodnego, stale dostępnego portalu informacyjnego. Infekcja i błędy 504 ograniczały dostęp do treści, a pozostawienie starego środowiska groziło powrotem problemu. Naprawa musiała zachować wygląd, treści i działanie podstron.
Ryzyka
Największym ryzykiem było pozostawienie furtki w plikach, których nazwy wyglądały poprawnie, lub w innych aplikacjach tego samego konta. Aktualizacja rdzenia i motywu mogła ujawnić niezgodności, a zależność od płatnego komponentu bez aktywnej licencji utrudniała bezpieczne utrzymanie.
Zakres odpowiedzialności
W modelu white-label wykonaliśmy kopie przed i po pracach, analizę infekcji, przywrócenie czystych plików WordPressa, aktualizację rdzenia, wtyczek i motywów, modernizację PHP i MySQL, zmianę środowiska na Apache, wymuszenie HTTPS, rotację haseł i kluczy oraz diagnostykę przeciążeń i testy frontu.
Rozwiązanie
WordPress został podniesiony z 6.2.2 do 7.0, PHP z 8.0 do 8.5, a baza z MySQL 5.7 do 8.0. Pliki rdzenia zastąpiliśmy oryginalnym pakietem, złośliwe skrypty i furtki usunęliśmy, a zależny od wygasłej licencji komponent zastąpiliśmy darmowym zgodnym odpowiednikiem. HTTPS został wymuszony w całym serwisie, a źródło nadmiarowych połączeń usunięte.
Architektura i integracje
Docelowe środowisko opiera się na WordPressie 7.0, PHP 8.5, MySQL 8, Apache i wymuszonym SSL/HTTPS. Wszystkie wtyczki i motywy zostały zaktualizowane, konta administracyjne zabezpieczone nowymi hasłami, a klucze bezpieczeństwa WordPressa obrócone.
Rezultaty
Strona główna i podstrony renderują się poprawnie, obrazy i style ładują się prawidłowo, a przyczyna przeciążenia i błędów 504 została usunięta. Powstała kopia sprzed ingerencji i kompletna kopia po zakończeniu prac. Klient otrzymał również zalecenie sprawdzenia pozostałych aplikacji na tym samym koncie.
Technologie
WordPress 6.2 i 7.0, PHP 8.0 i 8.5, MySQL 5.7 i 8.0, Apache, SSL/HTTPS, Elementor, czysty rdzeń WordPress, analiza malware, rotacja kluczy bezpieczeństwa, diagnostyka błędów 504.
Dalsze kroki
Rekomendujemy okresowe skany całego konta, stałe aktualizacje WordPressa, wtyczek i motywów, monitoring błędów 5xx oraz kontrolę pozostałych stron i aplikacji korzystających z tego samego hostingu.
Naprawa portalu bez ujawniania podmiotu
Serwis należy do podmiotu publicznego, ale realizacja została wykonana jako zaplecze partnera. Nie publikujemy nazwy, miasta, domeny, danych kontaktowych ani charakterystycznych fotografii. Pokazujemy rzeczywisty zakres naprawy i testów.

- Zainfekowane pliki systemowe zastąpiliśmy oryginalnym, czystym rdzeniem WordPressa.
- Wszystkie konta administracyjne otrzymały nowe hasła, a klucze bezpieczeństwa zostały obrócone.
- Płatny komponent zależny od wygasłej licencji zastąpiło bezpłatne, zgodne rozwiązanie zachowujące wygląd serwisu.
- Po przejściu na Apache, PHP 8.5 i MySQL 8 sprawdziliśmy stronę główną, podstrony, obrazy, style oraz obciążenie.
