WordPress łata krytyczną lukę CVE-2026-87902 prowadzącą do warunkowego RCE

Wprowadzenie do problemu / definicja

WordPress opublikował poprawkę dla krytycznej podatności CVE-2026-87902, która dotyczy mechanizmu rozstrzygania szablonów stron w rdzeniu systemu. Błąd umożliwia nieuwierzytelnionemu atakującemu doprowadzenie do lokalnego dołączenia pliku PHP spoza katalogów aktywnego motywu, a w określonych warunkach także do zdalnego wykonania kodu.

To szczególnie istotny problem, ponieważ luka występuje w samym rdzeniu WordPressa, a więc nie jest związana z opcjonalną wtyczką czy pojedynczym dodatkiem. Oznacza to szeroką powierzchnię ataku i konieczność pilnej reakcji po stronie administratorów.

W skrócie

Podatność została oznaczona jako krytyczna i otrzymała ocenę CVSS 9.2.
Problem dotyczy wersji WordPress od 4.7.0 do 7.1.1.
Poprawkę wydano 22 września 2026 r. w wersji 7.1.2 oraz przygotowano backporty dla wspieranych gałęzi.
Atak nie wymaga logowania, uprawnień ani interakcji użytkownika.
Pełne RCE zależy od dodatkowych warunków związanych z motywem i konfiguracją środowiska PHP.

Kontekst / historia

Podatność została zgłoszona w modelu responsible disclosure przez Roberta Ressla. Według opisu problem obejmuje ścieżkę przetwarzania szablonów stron, w której dochodzi do nieprawidłowej walidacji danych wpływających na wybór pliku template.

Znaczenie tej luki zwiększa fakt, że obejmuje ona zarówno relatywnie nowe wdrożenia, jak i starsze instalacje utrzymywane ze względów kompatybilnościowych. Dla operatorów dużych środowisk hostingowych oraz zespołów zarządzających flotami witryn oznacza to konieczność szybkiego sprawdzenia stanu aktualizacji i polityk utrzymaniowych.

Analiza techniczna

Istotą problemu jest nieuwierzytelniony path traversal w procesie rozstrzygania szablonu strony. Mechanizm buduje nazwę pliku szablonu na podstawie wartości związanej z żądaniem HTTP, a w podatnych wersjach jeden z wariantów tej logiki nie był poprawnie zabezpieczony przed sekwencjami traversal.

W rezultacie atakujący może doprowadzić do dołączenia lokalnego pliku PHP znajdującego się poza dozwolonymi katalogami aktywnego motywu. Taki scenariusz sam w sobie nie oznacza jeszcze uruchomienia dowolnego kodu dostarczonego z zewnątrz, ale pozwala wykonać kod zawarty w istniejącym już pliku dostępnym na serwerze.

Praktyczna eskalacja do warunkowego zdalnego wykonania kodu zależy od spełnienia dodatkowych warunków. Wśród nich wskazuje się obecność w aktywnym motywie katalogu najwyższego poziomu, którego nazwa zaczyna się od prefiksu page-, na przykład page-templates. Znaczenie może mieć również konfiguracja PHP, w tym ustawienie register_argc_argv, ponieważ znane scenariusze wykorzystania lokalnych plików takich jak pearcmd.php mogą opierać się właśnie na tej opcji.

Po stronie producenta poprawka nie ogranicza się wyłącznie do uszczelnienia jednej ścieżki wejściowej. Zastosowano również dodatkowe ograniczenia sprawdzające, czy rozwiązywany szablon rzeczywiście pozostaje w dozwolonym obszarze katalogów motywu, co wskazuje na bardziej defensywne podejście do eliminacji klasy błędu.

Konsekwencje / ryzyko

Najpoważniejszym zagrożeniem jest możliwość ataku bez uwierzytelnienia. To znacząco obniża próg wejścia dla automatycznych kampanii skanujących i masowych prób eksploatacji. Ze względu na szeroki zakres podatnych wersji problem może dotyczyć bardzo dużej liczby publicznie dostępnych instalacji.

W podstawowym scenariuszu luka umożliwia lokalne dołączenie pliku PHP, co może prowadzić do naruszenia integralności działania aplikacji lub ujawnienia niepożądanej logiki wykonawczej. W bardziej niebezpiecznym wariancie, przy spełnieniu dodatkowych warunków środowiskowych, możliwe jest osiągnięcie RCE, a następnie pełne przejęcie witryny, wdrożenie webshella, modyfikacja treści lub kradzież danych.

Ryzyko operacyjne podnosi również fakt, że luka znajduje się w rdzeniu WordPressa. Oznacza to, że nawet środowiska z ograniczoną liczbą wtyczek i rozszerzeń nie są automatycznie chronione przed tym zagrożeniem.

Rekomendacje

Najważniejszym krokiem jest natychmiastowe wdrożenie aktualizacji bezpieczeństwa do odpowiedniej wersji naprawczej. Administratorzy powinni także potwierdzić, że mechanizmy automatycznych aktualizacji zadziałały poprawnie na wszystkich utrzymywanych instancjach.

zaktualizować WordPress do wersji naprawczej w używanej gałęzi lub do najnowszego stabilnego wydania,
sprawdzić, czy aktywny motyw zawiera katalog najwyższego poziomu rozpoczynający się od page-,
zweryfikować ustawienie register_argc_argv w środowisku PHP,
przeanalizować obecność lokalnych plików PHP, które mogłyby zostać użyte w łańcuchu eksploatacji,
przejrzeć logi HTTP pod kątem nietypowych prób traversal i anomalii związanych z wyborem szablonów,
wdrożyć monitoring integralności plików WordPressa, motywów i katalogów uploadów.

W organizacjach utrzymujących wiele serwisów opartych o WordPress warto dodatkowo uruchomić skanowanie inwentarza wersji, potwierdzić zgodność polityk aktualizacyjnych i ograniczyć ekspozycję poprzez segmentację, WAF oraz zasadę najmniejszych uprawnień dla procesu serwera WWW.

Podsumowanie

CVE-2026-87902 to krytyczna podatność w rdzeniu WordPressa, która łączy brak wymaganej autoryzacji z możliwością warunkowego przejścia do zdalnego wykonania kodu. Nawet jeśli pełna eksploatacja zależy od dodatkowych elementów środowiska, skala narażonych wdrożeń i charakter luki sprawiają, że problem należy traktować priorytetowo.

Dla zespołów bezpieczeństwa i administratorów kluczowe są szybka aktualizacja, przegląd konfiguracji motywów oraz środowiska PHP, a także analiza logów pod kątem oznak prób wykorzystania podatności. Zwłoka może zwiększyć ryzyko skutecznego kompromitowania podatnych witryn.