Luka w WordPressie do wersji 7.1.1, jak sprawdzić, czy Twoja strona jest bezpieczna

Łatka na krytyczną lukę w WordPressie wyszła 22 września, a pierwsze próby jej wykorzystania pojawiły się jeszcze tego samego dnia. Kto czekał z aktualizacją do weekendu, przez kilka dni miał na serwerze otwarte drzwi, o których wiedział już cały internet. Piszę o tym, bo w takich sytuacjach sama automatyczna aktualizacja nie zamyka sprawy.

Najważniejsze w skrócie

• WordPress 7.1.2 z 22 września 2026 łata lukę CVE-2026-87902 ocenioną na 9,2 w skali 10. Dotyczy wszystkich wersji od 4.7 do 7.1.1.
• Firma Patchstack zarejestrowała pierwszą próbę ataku o 13:49 polskiego czasu, ponad 2 godziny przed wpisem z ogłoszeniem na wordpress.org, a o 17:34 pierwszą próbę zapisania pliku na serwerze.
• W naszym pomiarze z 23 września 14 z 30 losowych stron firmowych na WordPressie działało na wersji co najmniej dwa wydania starszej niż 7.1.2.
• Sama aktualizacja zamyka lukę na przyszłość, ale nie mówi nic o tym, co działo się na stronie przed nią. To sprawdza się w logach serwera.

Co się stało 22 września

Luka pozwala osobie bez żadnego konta na stronie zmusić WordPressa do wczytania wybranego pliku PHP z serwera, czyli pliku z kodem, który serwer wykonuje. Wystarczy odpowiednio spreparowany adres. W najgorszym wariancie atakujący uruchamia na serwerze własny kod, a to oznacza pełne przejęcie strony.

Najgorszy wariant wymaga dwóch warunków. Aktywny motyw musi mieć w głównym katalogu folder zaczynający się od page-, a serwer musi mieć dostępny plik pearcmd.php z pakietu PEAR (starego zestawu narzędzi PHP) przy włączonym ustawieniu register_argc_argv. Brzmi to egzotycznie, ale atakujący sprawdzali 3 typowe miejsca instalacji tego pliku, czyli liczą na zwykłe, fabryczne konfiguracje serwerów. Nawet bez nich luka pozwala sprawdzić, czy strona jest podatna, i odczytać część plików.

Właściciel strony nie musi tego wszystkiego rozumieć. Od tego jest stała opieka nad WordPressem, w której ktoś pilnuje aktualizacji i logów, a nie przeglądanie forów w poszukiwaniu numerów CVE. Dla właściciela zostaje jedno pytanie, czyli czy jego strona dostała łatkę i kiedy.

Szczegóły techniczne opisał zespół WordPressa w ogłoszeniu wydania 7.1.2, a przebieg ataków firma Patchstack w swojej analizie. Poprawkę dostały też starsze gałęzie, aż do wersji 4.7.37, więc nawet bardzo stara instalacja może się załatać bez przeskoku o kilka wersji.

Dlaczego automatyczna aktualizacja mogła nie zdążyć

Automatyczna aktualizacja bezpieczeństwa wchodzi zwykle w ciągu kilkunastu godzin, a ataki zaczęły się tego samego dnia. WordPress sprawdza dostępność nowej wersji 2 razy na dobę i robi to przez wbudowany harmonogram zadań, który uruchamia się dopiero wtedy, gdy ktoś odwiedzi stronę. Na firmowej stronie z kilkudziesięcioma wejściami dziennie to bywa noc albo ranek następnego dnia.

Działa to trochę jak skrzynka pocztowa, którą listonosz opróżnia tylko wtedy, gdy akurat przechodzi obok. Na ruchliwej ulicy list wychodzi szybko, na bocznej czeka.

Są też strony, na których automatyczne aktualizacje ktoś kiedyś wyłączył, bo jedna z nich coś zepsuła. To zrozumiały odruch, tylko że wtedy łatka czeka na człowieka. Jak bezpiecznie przeprowadzić taką aktualizację, opisaliśmy w poradniku o aktualizacji WordPressa, rdzenia, wtyczek i PHP.

Ile polskich stron stało na starszej wersji

Dzień po wydaniu łatki sprawdziliśmy 30 losowych stron polskich firm zbudowanych na WordPressie. Na 14 z nich, czyli prawie połowie, wersja WordPressa była co najmniej dwa wydania starsza niż 7.1.2. Pomiar robiliśmy z zewnątrz, na podstawie wersji, którą strona sama podaje w kodzie albo w kanale RSS.

Trzeba tu uczciwie postawić granicę. Starsza wersja nie oznacza automatycznie podatnej, bo poprawkę dostały też starsze gałęzie. Strona na wersji 6.8 jest bezpieczna, jeśli ma 6.8.10. Tyle że strony, które od miesięcy nie przeszły na nowsze wydanie, to zwykle te same, na których nikt nie zagląda do aktualizacji w ogóle.

Gdy aktualizacja się nie udaje i strona po niej nie działa, właściciel często wraca do starej wersji i tak zostaje. Jak z tego wyjść, żeby nie zostać na dziurawym rdzeniu, piszemy w tekście o tym, co zrobić, gdy aktualizacja WordPressa się nie powiodła.

Po czym poznać, że ktoś już próbował

Ślady próby ataku zostają w logach dostępu serwera, czyli w zapisie każdego zapytania do strony. Większość hostingów udostępnia je w panelu, a jak do nich dotrzeć i jak je czytać, opisaliśmy w poradniku o tym, jak sprawdzić ataki na WordPressa. Przy tej luce szukasz w nich czterech charakterystycznych wzorców:

• parametru pagename zawierającego %2e%2e albo %252e%252e, czyli zakodowane przejście do katalogu wyżej,
• wartości pagename zaczynającej się od templates%2f albo innej nazwy folderu z page-,
• słów pearcmd, config-show albo config-create w adresie,
• parametrów pagename i page_id w jednym zapytaniu do strony głównej albo do index.php.

Sama próba w logach to jeszcze nie włamanie. Groźny jest dopiero ślad, że zadziałała. Jeśli zwykły adres strony zwrócił kod 200 z treścią kanału RSS albo listy OPML zamiast strony, luka zadziałała na Twoim serwerze. Jeśli w katalogach /tmp albo /var/tmp leżą nieznane pliki .php, na przykład o nazwach zaczynających się od luci_, zeta_ albo poc87902, atakujący wykonał już na serwerze swój kod i stronę trzeba traktować jako przejętą.

Patchstack notuje próby z kilkuset adresów naraz, więc blokowanie pojedynczych adresów IP niczego nie załatwia. Jak wygląda strona już przejęta, pokazaliśmy na przykładzie poprzedniej luki, w tekście o tym, co zobaczyliśmy na stronach klientów przy krytycznej luce 24 lipca. Były tam konta, których nikt nie zakładał, i obce pliki dopisane na serwerze.

Co zrobić dziś

Najpierw sprawdź wersję w kokpicie WordPressa, w zakładce Aktualizacje. Wersja 7.1.2 albo nowsza, ewentualnie łatka na Twojej gałęzi (7.0.6, 6.9.9, 6.8.10 i starsze), oznacza, że luka jest zamknięta. Potem 3 kroki w tej kolejności.

1. Przejrzyj logi dostępu od 22 września do dnia aktualizacji pod kątem wzorców z poprzedniej sekcji.
2. Poproś hosting o sprawdzenie katalogów tymczasowych i o wyłączenie register_argc_argv, jeśli nie jest potrzebne. To ustawienie nie łata luki, ale przerywa drogę do wykonania kodu.
3. Jeśli znajdziesz którykolwiek ze śladów udanej próby, nie poprzestawaj na aktualizacji. Wtedy potrzebne jest czyszczenie strony po włamaniu, bo aktualizacja nie usuwa plików, które ktoś już zostawił na serwerze.

Jeśli nie masz czasu ani dostępu do logów, oddaj to komuś, kto robi to co miesiąc. W opiece technicznej WP Plan aktualizacje bezpieczeństwa i przegląd logów są w stałym zakresie prac. Ile to kosztuje przy Twojej stronie, pokazuje cennik opieki WordPress.

Pytania i odpowiedzi

Autor: Marcin Osak

Założyciel agencji interaktywnej Avangardo, którą prowadzi od 2008 roku. Tworzy strony i sklepy internetowe. Od lat pasjonuje się SEO, a od kilku lat także AI i optymalizacją stron pod wyszukiwanie generatywne (GEO). Ma za sobą ponad 1000 zrealizowanych projektów dla firm z całej Polski i Europy.

Zobacz profil autora