WordPress 7.1.2 zamyka drogę do RCE — poprawkę dostały też stare wersje

Zgodnie z biuletynem bezpieczeństwa WordPressa 22 września 2026 r. wydano WordPressa 7.1.2 z poprawką CVE-2026-87902, którą przeniesiono także do starszych gałęzi aż do 4.7. Podatność pozwala napastnikowi bez konta skierować wybór szablonu strony do czytelnego lokalnego pliku PHP poza katalogami aktywnego motywu. W określonej konfiguracji motywu i serwera może to doprowadzić do zdalnego wykonania kodu, czyli RCE.

W ostrzeżeniu CSA z 24 września 2026 r. singapurska agencja poinformowała o aktywnym wykorzystywaniu luki i zaleciła natychmiastową aktualizację. Administrator powinien ustalić numer faktycznie uruchomionego WordPressa na każdej witrynie: włączone aktualizacje automatyczne oznaczają ustawienie, a nie potwierdzenie zainstalowania poprawki. Naprawione wydanie istnieje również dla starszych gałęzi, więc decyzja nie sprowadza się do przejścia wszystkich witryn na najnowszą gałąź.

Które gałęzie dostały poprawkę

Dla każdej instalacji liczy się naprawione wydanie jej własnej gałęzi albo nowsza wersja WordPressa. Poniższy wykaz podaje najniższy numer z poprawką; wcześniejsze wydania wymienionych gałęzi są objęte podatnością. Dzięki temu właściciel wielu witryn może porównać każdą instalację osobno, bez zakładania, że aktualizacja jednej domeny objęła pozostałe.

• Gałęzie 7.x: 7.1 → 7.1.2; 7.0 → 7.0.6.
• Gałęzie 6.9–6.5: 6.9 → 6.9.9; 6.8 → 6.8.10; 6.7 → 6.7.9; 6.6 → 6.6.9; 6.5 → 6.5.12.
• Gałęzie 6.4–6.0: 6.4 → 6.4.12; 6.3 → 6.3.12; 6.2 → 6.2.13; 6.1 → 6.1.14; 6.0 → 6.0.16.
• Gałęzie 5.x: 5.9 → 5.9.18; 5.8 → 5.8.17; 5.7 → 5.7.19; 5.6 → 5.6.21; 5.5 → 5.5.22; 5.4 → 5.4.23; 5.3 → 5.3.25; 5.2 → 5.2.28; 5.1 → 5.1.26; 5.0 → 5.0.29.
• Gałęzie 4.x: 4.9 → 4.9.33; 4.8 → 4.8.32; 4.7 → 4.7.37.

Wykaz kończy się na gałęzi 4.7. Instalacja wcześniejszej wersji wymaga przejścia na wydanie, które otrzymuje poprawki bezpieczeństwa. Wśród witryn do sprawdzenia powinny znaleźć się także publicznie dostępne instalacje testowe i zapasowe: każda z nich uruchamia własny rdzeń WordPressa, niezależnie od wersji głównej witryny.

Kiedy podatność może doprowadzić do RCE

Błąd dotyczy funkcji wyboru szablonu strony. Odpowiednio przygotowane żądanie może sprawić, że WordPress włączy istniejący na serwerze plik PHP spoza katalogów aktywnego motywu. Atakujący nie musi logować się do witryny, lecz samo uruchamianie podatnej wersji nie oznacza jeszcze, że na danym serwerze da się wykonać dowolny kod.

Znaczenie ma struktura aktywnego motywu potomnego lub nadrzędnego: w jego katalogu głównym musi istnieć podkatalog, którego nazwa zaczyna się od page-. Taki układ występuje między innymi w motywach Twenty Twelve, Twenty Fourteen, Neve, Hestia i Sydney. Potrzebny jest też plik PHP, który istnieje na serwerze i jest czytelny dla konta obsługującego witrynę. Nazwa motywu pomaga ocenić warunki ataku, lecz sama nie rozstrzyga, czy całe przejęcie byłoby możliwe.

Opisany łańcuch prowadzący do RCE może wykorzystać plik pearcmd.php, jeżeli jest dostępny na serwerze, a ustawienie PHP register_argc_argv ma wartość On. Wtedy parametry żądania mogą zostać przekazane do włączonego skryptu i posłużyć do zapisania pliku PHP z treścią kontrolowaną przez napastnika. Wyłączenie tego ustawienia przerywa wskazaną drogę przez pearcmd.php, ale nie usuwa błędu wyboru szablonu w podatnym rdzeniu. Dlatego ocenę konfiguracji należy oddzielić od decyzji o aktualizacji.

Jakie próby ataku już zaobserwowano

W analizie Patchstack opisano sondowanie witryn 22 września 2026 r. oraz późniejsze żądania wykorzystujące pearcmd.php do prób zapisu plików PHP. Początkowo sprawdzano, czy da się włączyć zwykły plik WordPressa i uzyskać odpowiedź wskazującą na podatność. Kolejne żądania dotyczyły dostępności pearcmd.php oraz zapisu pliku w katalogu tymczasowym serwera. To obserwacje ruchu zarejestrowanego przez firmę, a nie dowód skutecznego przejęcia każdej podatnej witryny.

Przy przeglądzie dzienników warto szukać parametru pagename z zakodowanymi sekwencjami przejścia między katalogami, takimi jak %2e%2e lub %252e%252e. Istotne są również żądania, w których pagename występuje razem z page_id, oraz odwołania do pearcmd. Należy uwzględnić zarówno adresy żądań GET, jak i treść żądań POST, jeśli została zachowana w dostępnych logach. Pojedynczy podejrzany wpis może oznaczać skanowanie; odpowiedź zawierająca treść włączonego pliku wskazuje już, że próba odczytu się powiodła.

Osobnego sprawdzenia wymagają nieoczekiwane pliki PHP w katalogach /tmp i /var/tmp. Jeśli można powiązać taki plik z żądaniem wykorzystującym pearcmd.php, jest to przesłanka udanego zapisu, a nie tylko sondowania. Samo zainstalowanie poprawki zatrzyma przyszłe wykorzystanie tej luki w rdzeniu, lecz nie usunie pliku pozostawionego wcześniej ani nie wyjaśni, jakie działania wykonano przed aktualizacją.

Jak potwierdzić poprawkę na każdej witrynie

Potwierdzeniem wdrożenia jest numer wersji odczytany po aktualizacji i porównany z naprawionym wydaniem właściwej gałęzi. Dla większej liczby instalacji przydaje się zestawienie domeny, odczytanej wersji i wyniku kontroli. Pozwala ono odróżnić witrynę już poprawioną od takiej, której aktualizacja dopiero czeka w kolejce lub zakończyła się błędem.

1. Otwórz obszar „Aktualizacje” w panelu administracyjnym każdej witryny i zapisz numer jej rdzenia WordPressa. Ujmij również dostępne z internetu instalacje testowe oraz witryny utrzymywane na oddzielnych kontach hostingowych.
2. Porównaj odczytany numer z wykazem naprawionych wydań. Jeśli jest niższy, zainstaluj poprawkę dla tej gałęzi albo przejdź na nowszą wersję przewidzianą w planie utrzymania witryny.
3. Po zakończeniu aktualizacji ponownie odczytaj numer wersji i sprawdź działanie witryny. Gdy panel lub hosting pokazuje błąd bądź oczekujące zadanie, nie zapisuj instalacji jako poprawionej tylko na podstawie ustawienia aktualizacji automatycznych.
4. Sprawdź, czy automatyczne aktualizacje rdzenia są włączone oraz kto otrzymuje powiadomienia o ich niepowodzeniu. To zabezpieczenie na przyszłość; wynik bieżącej kontroli powinien nadal opierać się na odczytanej wersji.
5. Jeżeli witryna była dostępna przed zainstalowaniem poprawki, przejrzyj zachowane logi i katalogi tymczasowe pod kątem opisanych śladów. Gdy analiza wskazuje na zapis pliku lub wykonanie kodu, potraktuj to jako odrębny incydent wymagający zbadania serwera.

Najpilniejsza pozostaje aktualizacja instalacji uruchamiających wydanie starsze od poprawki dla swojej gałęzi. Po niej odczyt numeru odpowie na pytanie o stan rdzenia, a przegląd wcześniejszych zdarzeń pozwoli ustalić, czy w okresie podatności doszło do czegoś więcej niż prób skanowania.

Przeczytaj także:

• Copilot dostał lokalną piaskownicę, lecz ochrona jest domyślnie wyłączona
• Plany XTB dostały akcje, lecz gotowego składu nie można edytować