Krytyczna luka w WordPressie atakowana od pierwszego dnia. Co wiemy o CVE-2026-87902

Ostatni tydzień września był dla administratorów stron na WordPressie wyjątkowo nerwowy. 22 września twórcy systemu wydali awaryjną poprawkę krytycznej luki w samym rdzeniu WordPressa, a pierwsze próby jej wykorzystania pojawiły się jeszcze tego samego dnia, kilka godzin po publikacji. Trzy dni później amerykańska agencja CISA wpisała podatność na listę luk aktywnie wykorzystywanych przez atakujących. Poniżej zbieramy, co wiadomo z oficjalnych komunikatów, kogo luka dotyczy i co trzeba zrobić, żeby strona nie stała się kolejną ofiarą.

Co się stało: WordPress 7.1.2 i luka CVE-2026-87902

We wtorek 22 września 2026 roku zespół WordPressa opublikował wydanie bezpieczeństwa 7.1.2. W przeciwieństwie do zwykłych aktualizacji zawiera ono jedną jedyną zmianę: poprawkę podatności oznaczonej jako CVE-2026-87902 (w bazie GitHub: GHSA-7hp8-65ch-5whp). WordPress nadał jej najwyższy poziom ważności, czyli „krytyczny”, a w oficjalnym biuletynie ocenił ją na 9,2 w skali CVSS 4.0. Część agencji, na przykład singapurska CSA, podaje niższą ocenę 8,1, ale wszystkie źródła zgadzają się co do jednego: aktualizację trzeba zainstalować natychmiast.

Lukę zgłosił badacz Robert Ressl. Dotyczy mechanizmu, który decyduje o tym, jaki szablon strony ma zostać użyty do wyświetlenia podstrony. Nieuwierzytelniony atakujący, czyli ktoś bez żadnego konta w serwisie, może zmusić funkcję get_page_template() do wczytania wybranego pliku PHP spoza katalogu motywu. W sprzyjających warunkach kończy się to zdalnym wykonaniem kodu, a więc przejęciem strony: podmianą treści, wgraniem tylnej furtki, kradzieżą danych czy rozsyłaniem spamu.

Warto zauważyć, że to nie pierwsza taka poprawka w tym miesiącu. Już 17 września ukazało się wydanie 7.1.1 z jedenastoma poprawkami bezpieczeństwa, między innymi dla podatności typu XSS i błędu pozwalającego nadpisywać cudze wpisy. Wersja 7.1.2 pojawiła się zaledwie pięć dni później.

Kto jest zagrożony

Podatne są wszystkie wersje WordPressa od 4.7.0 do 7.1.1. To praktycznie każda instalacja, która nie dostała jeszcze aktualizacji. Samo wczytanie obcego pliku PHP to jednak dopiero pierwszy krok. Aby atak zakończył się pełnym przejęciem serwera, muszą zostać spełnione dwa warunki:

• Układ motywu. Aktywny motyw (albo jego motyw nadrzędny) ma w głównym katalogu folder, którego nazwa zaczyna się od page-, na przykład page-templates. Biuletyn WordPressa wymienia tu między innymi Twenty Twelve, Twenty Fourteen, Neve, Hestia i Sydney.
• Plik PHP, który da się nadużyć. Na serwerze musi istnieć plik PHP możliwy do wykorzystania. W praktyce najczęściej jest to pearcmd.php z menedżera pakietów PEAR, działający w połączeniu z włączoną opcją register_argc_argv. Taki zestaw występuje w oficjalnych obrazach Dockera z PHP i w części starszych konfiguracji hostingów opartych o cPanel.

Dlatego nie każda niezałatana strona zostanie przejęta. Atakujący nie wiedzą jednak z góry, która instalacja spełnia warunki, więc skanują wszystkie. Właściciel strony też zwykle nie wie, czy na serwerze hostingodawcy leży PEAR i jak ustawiono PHP. Zakładanie, że „mnie to nie dotyczy”, jest więc złym pomysłem.

Oś czasu: od poprawki do ataków w kilka godzin

Najlepiej widać to na chronologii zdarzeń, odtworzonej na podstawie komunikatów producenta, firm bezpieczeństwa i agencji rządowych:

• 22 września: WordPress publikuje wersję 7.1.2 i biuletyn bezpieczeństwa.
• 22 września, 11:49 UTC: firma Patchstack rejestruje pierwszą próbę ataku. Na tym etapie atakujący sprawdzają reakcję plików rdzenia, takich jak wp-links-opml.php.
• 22 września, 15:34 UTC: pierwsza próba zapisania pliku na serwerze przez pearcmd.php, czyli przejście od rozpoznania do właściwego ataku.
• 23 września: w sieci krąży publiczny exploit i gotowe szablony do automatycznego skanowania. Ruch atakujących osiąga szczyt około południa. Tego samego dnia kanadyjskie Centrum Cyberbezpieczeństwa wydaje ostrzeżenie AV26-952.
• 24 września: singapurska agencja CSA potwierdza aktywne wykorzystywanie luki i dostępność działającego kodu PoC.
• 25 września: CISA dodaje CVE-2026-87902 do katalogu Known Exploited Vulnerabilities. Amerykańskie agencje federalne dostały czas na załatanie systemów do 28 września.

Czas od publikacji poprawki do pierwszych ataków liczy się dziś w godzinach, nie w dniach. Atakujący porównują starą i nową wersję kodu, odczytują z różnic, gdzie był błąd, i od razu budują narzędzia. Kto aktualizuje strony „przy okazji”, raz w miesiącu, zostawia drzwi otwarte przez kilka tygodni.

Jak wygląda atak w praktyce

Z analizy Patchstacka wynika, że atak przebiega w trzech etapach. Najpierw rozpoznanie, czyli sprawdzenie, czy serwer reaguje na spreparowane zapytania z sekwencjami ../ w parametrze adresu. Potem test, czy na serwerze jest pearcmd.php. Na końcu zapis pliku PHP do katalogu tymczasowego /tmp lub /var/tmp i jego uruchomienie.

Część wgrywanych plików zawiera tylko nieszkodliwy znacznik. Służą do budowania list podatnych serwerów, które można zaatakować później albo sprzedać. Inne to już krótkie skrypty wykonujące polecenia systemowe. Patchstack wymienia takie nazwy plików jak wp-pear-rce-flag.php, poc87902.php, luci_[losowe znaki].php i zeta_[losowe znaki].php.

Co zrobić teraz: lista kontrolna dla właściciela strony

Dobra wiadomość jest taka, że poprawkę przygotowano dla wszystkich gałęzi WordPressa, które wciąż dostają łatki bezpieczeństwa, aż do wersji 4.7. Poprawione wydania to 7.1.2, 7.0.6, 6.9.9, 6.8.10 i odpowiednie wersje starszych gałęzi, aż do 4.7.37. Jeśli na stronie działają automatyczne aktualizacje wersji pomniejszych, a tak jest domyślnie, poprawka mogła się już zainstalować sama. Nie warto jednak zakładać tego w ciemno. Oto co warto sprawdzić:

• Wersja WordPressa. W kokpicie w zakładce Kokpit – Aktualizacje albo poleceniem wp core version sprawdź, czy strona ma 7.1.2 lub poprawione wydanie ze swojej gałęzi. Jeśli nie, zaktualizuj od razu.
• Automatyczne aktualizacje. Upewnij się, że nikt nie wyłączył aktualizacji bezpieczeństwa, na przykład stałą w wp-config.php, wtyczką albo ustawieniem w panelu hostingu.
• Katalogi tymczasowe. Poproś hostingodawcę albo administratora serwera o sprawdzenie, czy w /tmp i /var/tmp nie ma nieoczekiwanych plików .php. Według Patchstacka ich obecność oznacza udany atak, a serwer należy traktować jako przejęty.
• Logi serwera. Szukaj zapytań z zakodowanymi sekwencjami %2e%2e lub %252e%252e w parametrze pagename, a także odwołań do pearcmd.
• Konfiguracja PHP. Jeśli aktualizacja z jakiegoś powodu musi poczekać, wyłączenie register_argc_argv i usunięcie nieużywanego PEAR odcina najpopularniejszą drogę do wykonania kodu. To jednak tylko doraźna osłona, nie zamiennik łatki.
• Zapora aplikacyjna. Reguły WAF blokujące sekwencje przejścia do katalogu nadrzędnego w parametrach adresu dają dodatkowy czas, ale również nie zastępują aktualizacji.
• Po włamaniu. Jeśli ślady ataku się potwierdzą, sama aktualizacja nie wystarczy. Trzeba znaleźć i usunąć tylne furtki, sprawdzić konta administratorów, zmienić hasła i klucze w wp-config.php, a najlepiej odtworzyć stronę z kopii sprzed ataku.

Dlaczego część stron wciąż jest podatna

Skoro WordPress sam instaluje poprawki bezpieczeństwa, można by sądzić, że problem rozwiązał się bez udziału właścicieli stron. W praktyce sporo instalacji tej ochrony nie ma. Agencje i programiści często wyłączają automatyczne aktualizacje, bo obawiają się, że zmiana w rdzeniu zepsuje rozbudowany motyw albo wtyczkę pisaną na zamówienie. Część hostingów zarządza aktualizacjami po swojej stronie i robi to z opóźnieniem. Do tego dochodzą strony, o których wszyscy zapomnieli: stare landing page, wersje testowe, blogi po zakończonych kampaniach. Nikt ich nie odwiedza, ale wciąż działają pod publicznym adresem.

Automatyczna aktualizacja zawodzi też wtedy, gdy WordPress nie ma uprawnień do zapisu własnych plików, na przykład po zmianie właściciela katalogów na serwerze. Strona wygląda wtedy normalnie, a w kokpicie wisi jedynie komunikat o dostępnej aktualizacji, którego nikt nie czyta. Dlatego po takim tygodniu warto sprawdzić wersję ręcznie na każdej stronie, za którą się odpowiada.

Drugi alarm w rdzeniu WordPressa w ciągu dwóch miesięcy

Wrześniowa luka nie jest odosobniona. W lipcu 2026 roku świat WordPressa żył podatnościami nazwanymi WP2Shell (CVE-2026-63030 i CVE-2026-60137), które uderzały w punkt końcowy REST API /batch/v1. CERT Polska ostrzegał wtedy w komunikacie nr 124/2026, że „ataki nie wymagają konta użytkownika, zainstalowanych wtyczek ani niestandardowej konfiguracji”. Wiele stron, których nie zaktualizowano w porę, trzeba było potem czyścić z tylnych furtek i spamu.

Wniosek jest prosty: przez lata za większość włamań na WordPressa odpowiadały dziurawe wtyczki i motywy, a rdzeń uchodził za bezpieczny. Tegoroczne incydenty pokazują, że także sam system potrafi mieć poważne błędy, a atakujący są gotowi je wykorzystać w dniu publikacji poprawki. Automatyczne aktualizacje, regularne kopie zapasowe przechowywane poza serwerem i monitoring zmian w plikach przestają być dodatkiem dla ostrożnych. To dziś podstawowe wyposażenie każdej strony, która ma przetrwać kolejny taki tydzień.

Redakcja HotaruMiłośnicy nowych technologii

Redakcję Hotaru.pl tworzą doświadczeni copywriterzy, redaktorzy, specjaliści IT oraz pasjonaci nowych technologii. Łączy nas ciekawość świata, zamiłowanie do komputerów, elektroniki i oprogramowania, a także przekonanie, że nawet najbardziej złożone zagadnienia można wyjaśnić prostym i zrozumiałym językiem. Na bieżąco śledzimy rozwój sztucznej inteligencji, modeli LLM, sprzętu komputerowego oraz cyfrowych usług. Testujemy narzędzia, sprawdzamy informacje i oddzielamy rzeczywiste możliwości technologii od marketingowych obietnic. Każdy temat analizujemy z punktu widzenia specjalisty i użytkownika. Chcemy tworzyć treści rzetelne, praktyczne i przydatne, które pomagają lepiej rozumieć cyfrowy świat, podejmować świadome decyzje i wykorzystywać technologię w codziennym życiu.