Krytyczna luka w WordPressie – dlaczego aktualizacja do 7.0.2 to konieczność. Case study z naszego serwisu

17 lipca 2026 roku zespół bezpieczeństwa WordPressa opublikował wydanie 7.0.2 – i nie była to zwykła, rutynowa aktualizacja. Załatano dwie podatności (jedną krytyczną, jedną o wysokim priorytecie), które połączone w łańcuch pozwalały atakującemu wykonać własny kod na serwerze bez logowania – bez hasła, bez konta, bez żadnej podatnej wtyczki. Wystarczyła czysta, domyślna instalacja WordPressa i jedno anonimowe żądanie z Internetu.

Kilka dni po publikacji luki trafił do nas klient, którego serwer padł ofiarą dokładnie takiego ataku. To, co zastaliśmy, było podręcznikowym przykładem tego, jak jedna nieaktualna strona plus źle skonfigurowany serwer zamieniają lokalny incydent w infekcję wszystkich domen na hostingu. W tym artykule opisujemy ten przypadek krok po kroku – i wyjaśniamy, czym jest open_basedir, dlaczego współdzielenie katalogów to proszenie się o kłopoty oraz dlaczego usuwanie wirusów w takiej konfiguracji przypomina walkę z hydrą.

Co się stało? WordPress 7.0.2 w pigułce

Zanim przejdziemy do case study – krótko o samej luce, bo dotyczy ona praktycznie każdego, kto ma stronę na WordPressie:

• Data wydania poprawki: 17 lipca 2026
• Charakter podatności: ułatwiona iniekcja SQL oraz błąd w obsłudze zbiorczych żądań REST API, które połączone razem prowadziły do zdalnego wykonania kodu (RCE) bez uwierzytelnienia
• Wersje podatne: WordPress od 6.8.0 do 7.0.1
• Wersje bezpieczne: 7.0.2, 6.9.5, 6.8.6
• Skala zagrożenia: na tyle poważna, że WordPress.org włączył wymuszone automatyczne aktualizacje dla podatnych instalacji

To rzadka sytuacja – zdecydowana większość problemów bezpieczeństwa WordPressa dotyczy wtyczek, a nie samego rdzenia. Tym razem podatny był sam WordPress. Dlatego jeśli po zalogowaniu do kokpitu w zakładce Kokpit → Aktualizacje widzisz wersję inną niż 7.0.2 (lub 6.9.5 / 6.8.6 dla starszych gałęzi) – zaktualizuj stronę natychmiast. To dwie minuty pracy, które mogą oszczędzić tygodni sprzątania.

Case study: jedna luka, kilkanaście zainfekowanych domen

Do naszego działu wsparcia technicznego zgłosił się nowy klient z klasycznym zestawem objawów: strona przekierowuje na podejrzane witryny, Google oznaczył domenę jako niebezpieczną, poczta z serwera ląduje w spamie, a hosting wysłał ostrzeżenie o nadużyciach. Problem? Klient miał na jednym serwerze kilkanaście domen – strony firmowe, landing page, projekty testowe.

Nasza analiza logów wykazała, że punktem wejścia była jedna, dawno nieaktualizowana instalacja WordPressa – strona-wizytówka, o której wszyscy zapomnieli. Atakujący wykorzystał lukę, wgrał tzw. webshell (skrypt dający mu zdalną kontrolę) i… tu zaczyna się właściwa część tej historii.

Bo sama infekcja jednej strony to problem przykry, ale opanowalny. Prawdziwa katastrofa wynikała z konfiguracji serwera.

Czym jest open_basedir i dlaczego jego brak to otwarte drzwi

open_basedir to dyrektywa PHP, która ogranicza skryptom dostęp do plików wyłącznie w obrębie wskazanego katalogu. W praktyce: skrypt działający w katalogu domeny A nie może czytać ani zapisywać plików w katalogu domeny B, nawet jeśli obie leżą na tym samym serwerze.

Na serwerze naszego klienta open_basedir nie był ustawiony w ogóle. Efekt? Skrypt hakerski wgrany przez lukę w jednej stronie mógł swobodnie „spacerować” po całym systemie plików w zasięgu użytkownika – listować katalogi pozostałych domen, czytać pliki wp-config.php z hasłami do baz danych i dopisywać złośliwy kod do plików każdej kolejnej strony.

To dokładnie się wydarzyło. W ciągu kilku godzin od pierwszej infekcji automat atakującego:

• odczytał dane dostępowe do baz danych wszystkich instalacji WordPress i PrestaShop na serwerze,
• dopisał złośliwe przekierowania do plików index.php i .htaccess każdej domeny,
• rozsiał dziesiątki kopii webshelli w losowych katalogach – wp-includes, wp-content/uploads, katalogach motywów i wtyczek,
• utworzył ukryte zadania cron, które przywracały infekcję po każdej próbie czyszczenia.

Jedna luka. Kilkanaście zainfekowanych domen. I to nie dlatego, że wszystkie były podatne – tylko dlatego, że nic nie oddzielało ich od siebie.

Współdzielenie katalogów – jeden użytkownik, wiele domen

Drugim grzechem konfiguracji było to, że wszystkie domeny działały na jednym koncie użytkownika systemowego, ze wspólnymi uprawnieniami do plików. To niestety częsty scenariusz: tanie VPS-y konfigurowane „na szybko”, stare panele hostingowe albo sytuacja, w której kolejne strony dokładano latami do jednego konta, bo tak było wygodniej.

Taka architektura oznacza, że z punktu widzenia systemu każdy skrypt PHP każdej domeny ma identyczne prawa do plików wszystkich pozostałych domen. Nie ma znaczenia, że dziesięć stron jest zaktualizowanych i zabezpieczonych wzorowo – wystarczy jedna zaniedbana, by atakujący dostał klucze do całości. W branży bezpieczeństwa mówi się o tym „lateral movement” – ruch boczny. Bez separacji katalogów i użytkowników ten ruch nie napotyka żadnego oporu.

Prawidłowa konfiguracja wygląda tak:

• osobny użytkownik systemowy dla każdej domeny (lub przynajmniej dla każdego klienta/projektu),
• open_basedir ograniczony do katalogu danej strony plus niezbędne katalogi tymczasowe,
• PHP działające w trybie izolowanym (np. PHP-FPM z osobną pulą per domena),
• uprawnienia plików, które nie pozwalają na zapis tam, gdzie zapis nie jest potrzebny.

Dlaczego usuwanie wirusów w takiej konfiguracji jest tak trudne

Tu dochodzimy do sedna problemu, z którym mierzy się każdy, kto próbował „wyczyścić” zainfekowany serwer bez separacji domen. Usuwanie złośliwego kodu w takim środowisku to walka z hydrą – odcinasz jedną głowę, odrastają dwie:

1. Reinfekcja krzyżowa. Czyścisz domenę A, ale webshell ukryty w domenie B po godzinie ponownie dopisuje złośliwy kod do domeny A. Dopóki nie znajdziesz i nie usuniesz wszystkich kopii na wszystkich domenach jednocześnie, sprzątanie jest syzyfową pracą.
2. Nie wiadomo, co jest „czyste”. Skoro atakujący miał dostęp do wszystkiego, żadnemu plikowi nie można ufać. Trzeba weryfikować sumy kontrolne rdzenia WordPressa, każdą wtyczkę, każdy motyw – na każdej domenie osobno.
3. Skompromitowane dane dostępowe. Hasła do wszystkich baz danych, kluczy API i kont FTP należy uznać za wykradzione. Wszystkie – nie tylko te z zaatakowanej strony.
4. Mechanizmy przetrwania. Zadania cron, spreparowane wpisy w bazie danych, „uśpione” backdoory czekające tygodniami na ponowną aktywację. Automatyczne skanery antywirusowe hostingu zwykle znajdują tylko część z nich.

Dlatego koszt usunięcia infekcji z serwera bez separacji jest wielokrotnie wyższy niż z serwera poprawnie skonfigurowanego – i dlatego tak wiele „wyczyszczonych” stron wraca do punktu wyjścia po tygodniu.

Jak rozwiązaliśmy problem – krok po kroku

W opisywanym przypadku nasz zespół przeprowadził pełną procedurę naprawczą:

1. Odcięcie i diagnoza. Zablokowaliśmy ruch do zainfekowanych stron, zabezpieczyliśmy kopię materiału do analizy i na podstawie logów serwera ustaliliśmy wektor ataku oraz dokładną oś czasu infekcji.
2. Czyszczenie wszystkich domen równolegle. Porównaliśmy pliki każdej instalacji z oryginalnymi sumami kontrolnymi, usunęliśmy webshelle, złośliwe wpisy w .htaccess, zainfekowane pliki rdzenia oraz spreparowane zadania cron. Przeskanowaliśmy również bazy danych pod kątem wstrzykniętego kodu i fałszywych kont administratorów.
3. Aktualizacje. Wszystkie instalacje WordPressa zostały podniesione do wersji 7.0.2, wtyczki i motywy zaktualizowane, a nieużywane – usunięte. Porzucone strony testowe zostały za zgodą klienta całkowicie wyłączone.
4. Wymiana wszystkich danych dostępowych. Nowe hasła do baz danych, paneli administracyjnych, kont FTP/SFTP oraz nowe klucze i sole bezpieczeństwa WordPressa.
5. Separacja i utwardzenie serwera. Każda domena otrzymała osobnego użytkownika systemowego i własną pulę PHP-FPM z restrykcyjnym open_basedir. Wyłączyliśmy niebezpieczne funkcje PHP, wdrożyliśmy firewall aplikacyjny (WAF), monitoring integralności plików oraz automatyczne aktualizacje bezpieczeństwa.
6. Odzyskanie reputacji. Zgłosiliśmy oczyszczone strony do ponownej weryfikacji w Google Search Console, zdjęliśmy ostrzeżenia „strona może być niebezpieczna” i przywróciliśmy prawidłowe dostarczanie poczty.

Efekt: wszystkie strony wróciły do działania, a od zakończenia prac monitoring nie wykrył ani jednej próby reinfekcji. Co równie ważne – nawet gdyby w przyszłości któraś ze stron została skompromitowana, infekcja zostanie zamknięta w obrębie jednej domeny, a nie całego serwera.

Jak sprawdzić, czy Twój serwer jest podatny? Szybka checklista

Zanim zamkniesz ten artykuł, poświęć pięć minut na weryfikację:

1. Wersja WordPressa – Kokpit → Aktualizacje. Wszystko poniżej 7.0.2 (lub 6.9.5 / 6.8.6) wymaga natychmiastowej aktualizacji. Nie polegaj ślepo na auto-aktualizacjach – potrafią po cichu zawieść przy problemach z uprawnieniami plików.
2. open_basedir – utwórz plik z funkcją phpinfo() i sprawdź, czy dyrektywa jest ustawiona i wskazuje wyłącznie katalog Twojej strony. Wartość „no value” to czerwona lampka.
3. Liczba domen na jednym koncie – jeśli na jednym użytkowniku hostingu działa kilka niezależnych stron, każda z nich jest tak bezpieczna, jak najsłabsza z nich.
4. Zapomniane instalacje – stare wersje testowe, kopie w podkatalogach typu /old/, /backup/, /test/ to ulubione cele automatów skanujących sieć.
5. Kopie zapasowe – przechowywane poza serwerem, testowane, z historią co najmniej kilku tygodni wstecz. Backup na tym samym serwerze, który padł ofiarą ataku, bywa bezużyteczny.

Najczęstsze pytania (FAQ)

Czy aktualizacja do WordPress 7.0.2 może zepsuć moją stronę?

Wydania bezpieczeństwa zawierają wyłącznie poprawki, bez zmian funkcjonalnych, więc ryzyko jest minimalne. Mimo to przed aktualizacją warto wykonać kopię zapasową – a jeśli strona korzysta z wielu wtyczek lub modyfikacji, przetestować aktualizację na kopii roboczej.

Mam włączone automatyczne aktualizacje. Czy jestem bezpieczny?

Prawdopodobnie tak, ale zweryfikuj to. Automatyczne aktualizacje potrafią zawieść po cichu – przez konflikt wtyczki, problem z uprawnieniami plików czy wyłączony cron. Zajrzyj do kokpitu i sprawdź numer wersji na własne oczy.

Moja strona działa normalnie. Czy to znaczy, że nie została zhakowana?

Niestety nie. Nowoczesne infekcje często działają niezauważalnie – wysyłają spam, kopią kryptowaluty albo pokazują złośliwe treści wyłącznie robotom Google. Brak widocznych objawów nie jest dowodem czystości; jest nim dopiero skan integralności plików.

Czy wystarczy usunąć zainfekowane pliki?

Nie – to najczęstszy błąd. Bez ustalenia wektora ataku, wymiany haseł, aktualizacji i zabezpieczenia serwera infekcja wraca zwykle w ciągu kilku dni.

Podsumowanie

Historia tego klienta pokazuje trzy rzeczy naraz. Po pierwsze: aktualizacje bezpieczeństwa nie są opcjonalne – luka załatana w WordPress 7.0.2 pozwalała przejąć stronę jednym anonimowym żądaniem. Po drugie: konfiguracja serwera decyduje o skali szkód – brak open_basedir i współdzielenie katalogów zamieniły infekcję jednej zapomnianej strony w kompromitację kilkunastu domen. Po trzecie: usuwanie wirusów bez separacji domen to walka z hydrą – i dlatego prewencja jest zawsze tańsza niż sprzątanie.

Jeśli podejrzewasz, że Twoja strona mogła zostać zainfekowana, nie masz pewności, czy Twój serwer jest poprawnie odseparowany, albo po prostu chcesz spać spokojnie – napisz do nas. Przeprowadzimy audyt bezpieczeństwa, wyczyścimy zainfekowane strony i zabezpieczymy serwer tak, by następna głośna luka była dla Ciebie tylko newsem, a nie kryzysem. Zajmujemy się tym na co dzień w ramach wsparcia technicznego i hostingu zoptymalizowanego pod WordPress i PrestaShop.