CVE-2026-87902 w WordPressie – krytyczna luka w Core. Kogo dotyczy i jak ją naprawić?

I mamy kolejny czarny dzień dla Wordpress, w przyszłym rankingu bezpieczeństwa CMS chyba poleci na sam koniec.

Zobaczymy. W artykule o „ luce w SP Pagebuilder ” wspominałem że ostatnio mamy wysyp poważnych luk w bezpieczeństwie w najbardziej znanych systemach CMS, dzisiaj prezentuję kolejną i to poważną: luka CVE-2026-87902. To już kolejna poważna luka w Wordpress w ostatnim czasie. Poprzednie CVE-2026-63030 i CVE-2026-60137 skrzętnie opisałem w artykule: „ Krytyczne podatności WordPress CVE-2026-63030 i CVE-2026-60137 – co musisz wiedzieć i jak się zabezpieczyć ”.

CVE-2026-87902 dotyczy samego WordPress Core.

22 września 2026 roku zespół WordPressa opublikował WordPress 7.1.2 – wydanie bezpieczeństwa zawierające poprawkę dla podatności umożliwiającej nieuwierzytelnionemu użytkownikowi doprowadzenie, w określonych warunkach, do załadowania lokalnego pliku PHP znajdującego się poza katalogami aktywnego motywu.

W najbardziej niekorzystnej konfiguracji problem może zostać rozwinięty do Remote Code Execution , czyli wykonania kodu PHP na serwerze.

WordPress określił podatność jako krytyczną i zaleca natychmiastową aktualizację. Luka otrzymała identyfikator CVE-2026-87902 , a oficjalne advisory GitHub przypisuje jej ocenę CVSS 4.0: 9,2/10 .

To poważna luka, ale zanim zaczniemy mówić o „przejęciu wszystkich WordPressów”, warto dokładnie wyjaśnić, na czym polega problem.

 

Czym jest CVE-2026-87902?

Podatność znajduje się w mechanizmie odpowiedzialnym za wybór szablonu strony WordPressa.

WordPress, wyświetlając zwykłą stronę typu Page, musi zdecydować, którego pliku PHP z motywu użyć.

Może to być na przykład:

  
    page.php
page-about.php
page-123.php
page-templates/full-width.php
  

Za część tego procesu odpowiada funkcja:

  
    get_page_template()
  

znajdująca się w:

  
    wp-includes/template.php
  

Problem polegał na tym, że jedna ze ścieżek wykorzystywanych podczas budowania nazwy szablonu nie była odpowiednio zabezpieczona przed manipulacją ścieżką pliku.

WordPress wykorzystywał między innymi wartość pagename , na podstawie której powstawała nazwa:

  
    page-{pagename}.php
  

W podatnych wersjach odpowiednio przygotowana zakodowana wartość mogła po późniejszym wykonaniu urldecode() zmienić swoje znaczenie i zacząć zachowywać się jak ścieżka zawierająca przejścia do katalogów nadrzędnych.

W efekcie mechanizm szukający pliku szablonu mógł opuścić katalog aktywnego motywu.

Badacz Robert Ressl, który zgłosił podatność, opisuje problem jako błąd występujący na kilku kolejnych etapach przetwarzania żądania. Początkowo zakodowane elementy ścieżki nie były interpretowane jako przejście pomiędzy katalogami, natomiast po późniejszym dekodowaniu zaczynały mieć znaczenie dla systemu plików.

I właśnie tutaj pojawia się zasadniczy problem.

WordPress powinien szukać szablonu strony w kontrolowanych katalogach motywu.

Nie powinien pozwalać, aby wartość pochodząca z żądania HTTP spowodowała szukanie pliku PHP gdzieś indziej na serwerze.

 

Atakujący nie musi być zalogowany

Jedną z najważniejszych cech CVE-2026-87902 jest fakt, że luka może zostać zaatakowana bez posiadania konta WordPress .

• Nie jest wymagane konto administratora.
• Nie jest wymagany użytkownik Subscriber.
• Nie jest wymagany autor wpisów.
• Nie jest również wymagany nonce ani aktywna sesja użytkownika.
• W laboratoryjnej demonstracji przygotowanej przez autora podatności wykorzystywane były publicznie dostępne parametry żądania, a cały mechanizm działał bez uwierzytelnienia.

To znacząco podnosi poziom zagrożenia.

W przypadku luk wymagających konta administratora możliwości wykorzystania są zazwyczaj znacznie ograniczone. Tutaj potencjalnym źródłem żądania może być dowolny użytkownik Internetu mający dostęp do strony.

 

LFI, Path Traversal i RCE – trzy pojęcia, których nie należy mieszać

W publikacjach dotyczących CVE-2026-87902 można spotkać jednocześnie określenia:

Path Traversal , Local File Inclusion oraz Remote Code Execution .

Nie oznaczają one dokładnie tego samego.

Path Traversal oznacza możliwość manipulowania ścieżką w taki sposób, aby aplikacja wyszła poza katalog, w którym powinna operować.

Local File Inclusion, czyli LFI, idzie krok dalej – aplikacja zostaje zmuszona do załadowania lokalnego pliku znajdującego się na serwerze.

Jeżeli tym plikiem jest wykonywalny skrypt PHP, jego załadowanie przez include lub require może spowodować jego wykonanie.

Ale nadal nie oznacza to automatycznie, że atakujący może wpisać:

  
    <?php
dowolny_kod();
  

i WordPress go wykona.

Do pełnego RCE potrzebna jest możliwość znalezienia na serwerze odpowiedniego pliku PHP oraz spełnienia dodatkowych warunków pozwalających wykorzystać go jako element łańcucha prowadzącego do wykonania kontrolowanego kodu.

Dlatego najbardziej precyzyjne określenie tej podatności to:

nieuwierzytelnione Local File Inclusion mogące w określonych konfiguracjach prowadzić do Remote Code Execution.

Tak również opisują ją WordPress, autor podatności i Patchstack.

 

Czy każdy WordPress jest podatny na pełne RCE?

Nie.

I to bardzo ważne rozróżnienie.

Podatny kod znajdował się w WordPress Core przez wiele wersji, jednak skuteczne wykorzystanie pełnego łańcucha ataku zależy od konfiguracji strony, aktywnego motywu, systemu plików i środowiska PHP.

Autor CVE wyraźnie podkreśla, że jego badania nie dowodzą, że każda domyślna instalacja WordPressa jest możliwa do przejęcia .

W laboratorium wykorzystano WordPress 7.0.2 i specjalnie przygotowane środowiska pozwalające odtworzyć problem.

Nie zmienia to jednak faktu, że sam błąd znajduje się w WordPress Core, a jego potencjalne konsekwencje są na tyle poważne, że aktualizacja powinna zostać wykonana niezależnie od tego, czy administrator uważa swoją obecną konfigurację za możliwą do wykorzystania.

 

Dlaczego katalog page-templates jest tak interesujący?

Jednym z bardziej nietypowych elementów CVE-2026-87902 jest zależność od struktury katalogów aktywnego motywu.

WordPress sam dodaje do nazwy pliku prefiks:

  
    page-
  

Dlatego w demonstracji ataku potrzebny jest istniejący bezpośrednio w katalogu motywu katalog, którego nazwa zaczyna się od:

  
    page-
  

Najbardziej oczywistym przykładem jest:

  
    page-templates/
  

I tutaj robi się ciekawie.

page-templates nie jest podejrzaną nazwą stworzoną przez atakujących.

To całkowicie prawidłowy i od dawna używany sposób organizowania niestandardowych szablonów stron WordPressa.

Przykładowa struktura motywu może wyglądać tak:

  
    my-theme/
├── functions.php
├── style.css
├── page.php
└── page-templates/
    ├── full-width.php
    └── landing-page.php
  

Sam WordPress w swojej dokumentacji przedstawia page-templates/ jako prawidłowy sposób organizowania takich plików.

Co istotne, katalog może znajdować się zarówno w aktywnym child theme, jak i w jego motywie nadrzędnym.

Posiadanie katalogu page-templates nie oznacza jednak, że strona została zhakowana ani że pełne RCE jest możliwe .

Jest to jeden z warunków mogących przybliżyć konfigurację strony do scenariusza wykorzystanego przez badacza.

 

Jak sprawdzić swój motyw?

Jeżeli mamy dostęp SSH, możemy szybko sprawdzić, czy w katalogach motywów występują katalogi rozpoczynające się od page- .

Przykładowo:

  
    find wp-content/themes -maxdepth 2 -type d -name 'page-*'
  

Możemy otrzymać wynik podobny do:

  
    wp-content/themes/mytheme/page-templates
  

Nie jest to dowód podatności.

To jedynie informacja, że jeden z warunków przedstawionych w analizie CVE występuje w danym motywie.

Nie zalecam również „naprawiania” problemu poprzez pochopne kasowanie lub zmianę nazwy page-templates .

Jeżeli motyw korzysta z znajdujących się tam szablonów, możemy w ten sposób po prostu uszkodzić witrynę.

Prawidłową naprawą jest aktualizacja WordPress Core.

 

Jakie wersje WordPressa są podatne?

Według opublikowanych informacji problem dotyczy WordPressa od gałęzi 4.7 aż do wersji 7.1.1 włącznie .

WordPress 7.1.2 zawiera poprawkę.

Ze względu na wagę problemu zespół WordPressa przygotował również poprawione wydania dla starszych gałęzi.

Na dzień 23 września 2026 roku wygląda to następująco:

Gałąź WordPress	Wersja zawierająca poprawkę
7.1	7.1.2
7.0	7.0.6
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
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
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
4.9	4.9.33
4.8	4.8.32
4.7	4.7.37

WordPress 4.6 i starsze wersje nie otrzymują już tej aktualizacji bezpieczeństwa.

Trzeba przy tym pamiętać o bardzo ważnym zastrzeżeniu WordPressa: backport poprawki do starej gałęzi nie oznacza, że dana wersja WordPressa jest obecnie normalnie wspierana.

WordPress oficjalnie wskazuje, że aktywnie wspierana jest przede wszystkim najnowsza wersja.

Jeżeli więc ktoś nadal korzysta przykładowo z WordPressa 5.4 i z powodów technicznych nie może wykonać dużej aktualizacji, instalacja 5.4.23 zabezpieczy go przed CVE-2026-87902.

Nie oznacza jednak, że pozostawanie na WordPressie 5.4 jest dobrą długoterminową strategią bezpieczeństwa.

 

Jak sprawdzić wersję WordPressa?

Najprościej zalogować się do panelu administracyjnego.

Numer wersji można znaleźć między innymi w:

  
    Kokpit → Aktualizacje
  

Jeżeli mamy dostęp przez SSH i WP-CLI:

  
    wp core version
  

Możemy otrzymać na przykład:

  
    6.9.8
  

Taka instalacja wymaga aktualizacji co najmniej do wersji zawierającej poprawkę dla swojej gałęzi.

W WP-CLI możemy wykonać aktualizację:

  
    wp core update
  

a następnie – jeżeli WordPress tego wymaga:

  
    wp core update-db
  

Przed wykonaniem aktualizacji na stronie produkcyjnej nadal obowiązuje stara i dobra zasada: backup plików i bazy danych .

Aktualizacja bezpieczeństwa jest pilna, ale robienie jej bez kopii bezpieczeństwa na ważnym sklepie czy serwisie produkcyjnym nie jest dobrym pomysłem.

 

Jak naprawić CVE-2026-87902?

Najważniejsza odpowiedź jest bardzo prosta:

zaktualizować WordPress Core do wersji zawierającej poprawkę.

Dla aktualnej linii 7.1 jest to:

  
    WordPress 7.1.2
  

WordPress opublikował tę wersję 22 września 2026 roku i jednoznacznie zaleca natychmiastową aktualizację stron.

Możemy zrobić to w panelu:

  
    Kokpit
→ Aktualizacje
→ Aktualizuj teraz
  

lub poprzez WP-CLI:

  
    wp core update
  

Jeżeli strona działa na starszej gałęzi WordPressa, możemy zainstalować przygotowaną dla niej poprawkę bezpieczeństwa.

Przykładowo WordPress 6.8 powinien zostać zaktualizowany przynajmniej do:

  
    6.8.10
  

WordPress 6.6 do:

  
    6.6.9
  

a WordPress 5.9 do:

  
    5.9.18
  

Pełną listę aktualizacji publikuje WordPress.org.

 

Co dokładnie zmieniono w WordPressie?

Poprawka jest interesująca również z punktu widzenia programisty.

W podatnym kodzie sprawdzany był między innymi template slug:

  
    if ( $template && 0 === validate_file( $template ) ) {
    $templates[] = $template;
}
  

Natomiast ścieżka powstająca po dodatkowym urldecode() wartości pagename nie przechodziła analogicznej kontroli.

Po poprawce również zdekodowana wartość jest sprawdzana przez:

  
    validate_file()
  

WordPress zrobił jednak coś więcej.

Wprowadzono również dodatkową kontrolę ścieżki szablonu, której zadaniem jest upewnienie się, że w sytuacji zawierającej podejrzane przejścia pomiędzy katalogami ostatecznie rozwiązany plik pozostaje w dozwolonym obszarze motywu.

Patchstack zwraca uwagę, że oznacza to poprawienie nie tylko jednego konkretnego miejsca, ale również wprowadzenie dodatkowej ochrony całej klasy problemów dotyczących rozwiązywania ścieżek szablonów.

To dobra praktyka bezpieczeństwa.

Zamiast polegać wyłącznie na tym, że każdy fragment kodu prawidłowo oczyści swoją wartość wejściową, na końcu sprawdzamy również, czy wynikowa ścieżka rzeczywiście prowadzi tam, gdzie powinna.

 

Dlaczego realpath() nie wystarcza?

Ten przypadek jest również dobrym przykładem różnicy pomiędzy normalizacją ścieżki a kontrolą jej zakresu .

Załóżmy, że aplikacja otrzyma ścieżkę:

  
    /var/www/theme/page-templates/../../../../tmp/file.php
  

realpath() może zamienić ją na coś w rodzaju:

  
    /tmp/file.php
  

Ścieżka jest teraz „ładna”, jednoznaczna i prawidłowo rozwiązana.

Ale nadal znajduje się poza:

  
    /var/www/theme/
  

Normalizacja ścieżki nie odpowiada więc na pytanie:

Czy ten plik znajduje się w katalogu, któremu ufam?

Odpowiada jedynie:

Dokąd naprawdę prowadzi ta ścieżka?

I właśnie ten typ różnicy był istotny w przypadku CVE-2026-87902.

To cenna lekcja również dla autorów własnych wtyczek WordPress.

 

Skąd bierze się możliwość RCE?

Samo znalezienie lokalnego pliku PHP nie daje jeszcze atakującemu dowolnego wykonania kodu.

W laboratoryjnym scenariuszu autora podatności wykorzystano komponenty PEAR znajdujące się w środowisku PHP.

Jednym z elementów demonstracji był plik pearcmd.php .

Łańcuch zależał między innymi od obecności odpowiednich komponentów PEAR, ustawienia:

  
    register_argc_argv = On
  

oraz możliwości zapisu do odpowiedniego katalogu.

W przygotowanym środowisku pozwalało to wykorzystać LFI jako element prowadzący ostatecznie do wykonania kontrolowanego kodu PHP.

Należy jednak podkreślić:

PEAR nie jest zależnością WordPressa.

Nie każda instalacja WordPressa posiada pearcmd.php .

Nie każda konfiguracja PHP ma wymagane ustawienia.

Nie na każdym serwerze proces PHP ma dostęp do tych samych plików.

Nie każdy hosting pozwala na taki sam dostęp do systemu plików.

Dlatego mówimy o conditional RCE , czyli możliwości wykonania kodu zależnej od dodatkowych warunków.

 

Czy wyłączenie register_argc_argv naprawia problem?

Nie.

Może ono przerwać konkretny zaprezentowany łańcuch prowadzący przez PEAR do RCE, ale nie usuwa pierwotnej podatności WordPressa .

To samo dotyczy usunięcia PEAR.

Jeżeli serwer nie posiada PEAR, określona technika wykorzystana przez badacza nie zadziała.

Ale nadal może istnieć możliwość załadowania innego interesującego lokalnego pliku PHP.

Sam Robert Ressl wyraźnie zaznacza, że wyłączenie register_argc_argv lub usunięcie PEAR przerywa jego demonstracyjny scenariusz, ale nie naprawia podatności Local File Inclusion.

Dlatego nie należy traktować zmian PHP jako zamiennika aktualizacji WordPressa.

 

Jak sprawdzić register_argc_argv ?

Z poziomu terminala można wykonać:

  
    php -i | grep register_argc_argv
  

albo:

  
    php -r 'var_dump(ini_get("register_argc_argv"));'
  

Ale jest tutaj pułapka.

Konfiguracja PHP CLI może być inna niż konfiguracja PHP-FPM lub PHP uruchamianego przez Apache.

Możemy więc zobaczyć w SSH:

  
    register_argc_argv => Off
  

podczas gdy strona WWW działa z inną konfiguracją.

Jeżeli chcemy sprawdzić konfigurację wykorzystywaną faktycznie przez witrynę, należy zweryfikować ustawienia odpowiedniego SAPI – na przykład PHP-FPM.

I ponownie: nawet wynik Off nie oznacza, że aktualizacja WordPressa przestaje być potrzebna.

 

Czy WooCommerce jest podatny?

CVE-2026-87902 jest podatnością WordPress Core , a nie WooCommerce.

Jeżeli sklep WooCommerce działa na podatnej wersji WordPressa, problem dotyczy również jego instalacji.

WooCommerce nie musi być w tym przypadku źródłem błędu.

To ważne z praktycznego punktu widzenia.

Administrator może mieć:

  
    WooCommerce – aktualny
Elementor – aktualny
motyw – aktualny
wszystkie wtyczki – aktualne
  

a mimo to jego strona nadal będzie posiadała podatny WordPress Core.

Aktualizacja dodatków nie zastępuje aktualizacji samego WordPressa.

To jest największy problem Woocommerce i główny powód dla którego w naszym rankingu z zeszłego roku: "Ranking sklepów pod względem bezpieczeństwa" zajął ostatnie miejsce. 

W tym roku nic się nie zmieniło bynajmniej na korzyść Woocommerce.  

Jeżeli na sklepie internetowym haker może wykonać kod z pliku php może dosłownie wszystko. 

Może np. podmienić checkout/kasę sklepu internetowego na swoją spreparowaną tak by wyciągać dane kart klientów, lub nawet ściągać od nich płatności na własne konto. 

Pamiętam koło 2009 roku ratowałem stronę WWW jednego z klientów. Strona była oparta na CMS Mambo albo już Joomla w pierwszej wersji. Serwis został zhakowany, a zamiast strony wyświetlał się gif tańczącego pingwina z granatnikami z arabską piosenką w tle. 

Treść - to jedynie nick autora włamania.

Dzisiaj nikt tak nie robi. Haker też z czegoś musi żyć 😅. Dzisiaj włam wygląda tak że nie wiesz o tym, a haker na bieżąco eksportuje dane Twoich klientów do siebie w ciszy, umieszcza swój formularz płatności który wygląda jak Twój. 

Miałem wiele rozmów z klientami którzy przyszli do Design Cart po pomoc i powiem wam szczerze że większość nie miała pojęcia o zhakowaniu sklepu najczęściej sprawa wychodziła bo np. klient zapłacił i nie otrzymał żadnego info wiec zadzwonił do sprzedawcy, a sprzedawca miał dany koszyk oznaczony jako porzucony - "gdzie się podziały moje pieniądze? 🫣". 

 

A co z Elementorem?

Sytuacja jest podobna.

Samo używanie Elementora nie jest przyczyną CVE-2026-87902.

Trzeba jednak pamiętać, że istotna dla możliwości wykorzystania LFI jest między innymi struktura aktywnego motywu.

Jeżeli witryna korzysta przykładowo z child theme zawierającego:

  
    page-templates/
  

jest to jeden z elementów, które warto sprawdzić podczas oceny ekspozycji.

Nie oznacza to jednak, że Elementor czy Hello Elementor są automatycznie podatne na RCE.

Źródłem CVE pozostaje WordPress Core.

 

Czy klasyczne motywy są bardziej interesujące niż block themes?

Historycznie katalog:

  
    page-templates/
  

był bardzo popularnym sposobem organizowania niestandardowych szablonów w klasycznych motywach WordPressa.

Można więc przypuszczać, że podczas audytu warto zwrócić szczególną uwagę właśnie na starsze i mocno rozbudowane motywy klasyczne.

Nie powinno się jednak na tej podstawie uznawać konkretnego motywu za podatny bez jego sprawdzenia.

Co ciekawe, Robert Ressl podczas swoich badań sprawdził wersje motywów Twenty Twenty-Three, Twenty Twenty-Four i Twenty Twenty-Five. Nie posiadały one wymaganego katalogu najwyższego poziomu page-* .

W jego laboratorium taki katalog został dodany celowo, aby spełnić warunek testu.

To bardzo istotna informacja, ponieważ pokazuje, dlaczego zdanie:

Każdy standardowy WordPress można zdalnie przejąć

byłoby nieprawdziwym uproszczeniem.

 

Czy samo posiadanie  page-templates oznacza włamanie?

Absolutnie nie.

Jeżeli po przeczytaniu tego artykułu znajdziesz:

  
    wp-content/themes/nazwa-motywu/page-templates/
  

nie kasuj katalogu w panice.

To normalna struktura stosowana przez wiele motywów.

Jej obecność nie jest oznaką infekcji.

Jest jedynie jednym z warunków, który może mieć znaczenie dla CVE-2026-87902.

Naprawiamy WordPressa, a nie legalną strukturę naszego motywu.

 

Co zrobić po aktualizacji?

Jeżeli aktualizujesz stronę odpowiednio szybko po publikacji poprawki i nie masz żadnych innych przesłanek wskazujących na włamanie, nie oznacza to automatycznie konieczności stawiania witryny od nowa.

W przypadku ważnych serwisów warto jednak wykonać podstawową kontrolę.

Sprawdziłbym przede wszystkim aktualną wersję Core, integralność plików WordPressa, ostatnio zmodyfikowane pliki PHP, nietypowe pliki w katalogach zapisywalnych oraz logi WWW z okresu poprzedzającego aktualizację.

WP-CLI pozwala na przykład sprawdzić sumy kontrolne plików Core:

  
    wp core verify-checksums
  

Poprawna instalacja powinna przejść kontrolę plików pochodzących z oficjalnej paczki WordPressa.

Jeżeli pojawiają się ostrzeżenia dotyczące:

  
    wp-admin/
wp-includes/
  

warto dokładniej sprawdzić wskazane pliki.

Pamiętajmy jednak, że:

  
    wp core verify-checksums
  

nie sprawdzi za nas całego:

  
    wp-content/
  

czyli wtyczek, motywów i plików przesłanych na serwer.

 

Wyszukiwanie ostatnio zmienionych plików PHP

Na serwerze linuksowym przydatne może być przykładowo:

  
    find . -type f -name "*.php" -mtime -7 -print
  

Polecenie pokaże pliki PHP zmodyfikowane w ostatnich siedmiu dniach.

Możemy również zawęzić wyszukiwanie do wp-content :

  
    find wp-content -type f -name "*.php" -mtime -7 -print
  

Sam fakt niedawnej modyfikacji pliku oczywiście nie oznacza infekcji.

Aktualizacja wtyczki, motywu czy WordPressa również zmienia pliki.

Polecenie pomaga jednak szybko znaleźć anomalie wymagające dalszego sprawdzenia.

 

Szczególnie podejrzane miejsca

W typowej instalacji WordPressa warto zwrócić uwagę na obecność plików PHP w katalogach, w których normalnie powinny znajdować się głównie pliki przesłane przez użytkownika.

Najbardziej oczywistym przykładem jest:

  
    wp-content/uploads/
  

Można wykonać:

  
    find wp-content/uploads -type f -name "*.php" -print
  

Plik PHP znaleziony w uploads nie jest automatycznie malware – niektóre dodatki rzeczywiście tworzą tam własne struktury – ale zdecydowanie zasługuje na sprawdzenie.

 

Czy WAF wystarczy?

Firewall aplikacyjny może ograniczyć możliwość wykorzystania podatności.

Niektóre systemy bezpieczeństwa przygotowały reguły filtrujące żądania związane z CVE-2026-87902. Patchstack poinformował na przykład o wdrożeniu reguły RapidMitigate dla chronionych przez siebie witryn.

WAF jest jednak warstwą dodatkową.

Nie traktowałbym go jako wymówki do pozostawienia starego WordPressa.

Najlepsza sytuacja wygląda tak:

  
    poprawiony WordPress
+
aktualne PHP
+
rozsądne uprawnienia
+
ograniczony dostęp procesu PHP
+
WAF
+
monitoring
+
backup
  

a nie:

  
    podatny WordPress
+
mamy Cloudflare, więc nic nam nie grozi
  

Ostatnio prezentowałem na blogu przypadek gdzie jedna strona miała aktywny WAF a druga wyłączony. Przypadek luki SP Page Builder. Obie były zaatakowane tą samą drogą przez tą samą lukę w bezpieczeństwie.

Strona z dezaktywowanym WAF była zasypana złośliwymi plikami. Strona z aktywnym WAF atak przeżyła i ma się dobrze. 

 

Dlaczego aktualizacja Core jest ważniejsza niż kombinowanie z obejściami?

Przy każdej większej podatności pojawia się pokusa stworzenia własnego „szybkiego fixa”.

• Można zmienić nazwę katalogu.
• Można dodać regułę do htaccess .
• Można filtrować podejrzane parametry.
• Można zmienić register_argc_argv .
• Można usunąć PEAR.

Część tych działań może ograniczać powierzchnię ataku.

Ale mamy już poprawkę przygotowaną przez twórców WordPressa.

Co więcej, poprawka nie ogranicza się do jednego prostego filtra. WordPress dodał również dodatkowy mechanizm kontrolujący dopuszczalne ścieżki szablonów.

Dlatego podstawowe działanie administratora powinno być proste:

zaktualizuj Core.

Dopiero później zajmuj się dodatkowym hardeningiem.

 

Co powinien zrobić właściciel zwykłej strony WordPress?

Jeżeli administrujesz jedną stroną i nie interesuje Cię analiza techniczna podatności, sprowadza się to właściwie do kilku minut pracy.

Sprawdź numer WordPressa.

Zrób kopię bezpieczeństwa.

Wejdź do:

  
    Kokpit → Aktualizacje
  

i zainstaluj najnowszą dostępną aktualizację bezpieczeństwa.

Po aktualizacji sprawdź, czy strona działa poprawnie.

Jeżeli korzystasz z cache – wyczyść cache.

Jeżeli posiadasz sklep WooCommerce – wykonaj krótki test koszyka i zamówienia.

Jeżeli masz formularze – sprawdź wysyłkę.

I tyle.

Nie trzeba szukać wymyślnych zabezpieczeń, jeżeli producent naprawił problem w kodzie.

 

Co powinien zrobić administrator wielu WordPressów?

Tutaj sprawa wygląda trochę inaczej.

CVE-2026-87902 dotyczy bardzo szerokiego zakresu wersji, sięgającego WordPressa 4.7.

W agencji, software house albo firmie utrzymującej wiele stron może się więc okazać, że problem obejmuje zarówno nowe serwisy, jak i instalacje, do których nikt nie zaglądał od kilku lat.

W takim środowisku warto zinwentaryzować wszystkie instalacje i ich wersje.

Przy dostępie SSH oraz WP-CLI można szybko zebrać informacje o wersjach Core i następnie zaktualizować kolejne witryny.

Jeżeli część klientów posiada stare instalacje WordPressa, dla których duża aktualizacja wymagałaby testów kompatybilności, przygotowane przez WordPressa backporty pozwalają przynajmniej zainstalować poprawkę bezpieczeństwa bez natychmiastowego przechodzenia z WordPressa 5.x na 7.1.

Nie powinno to jednak stać się wymówką do dalszego utrzymywania archaicznego środowiska przez kolejne lata.

 

CVE-2026-87902 pokazuje jeszcze jeden problem

Przez lata przyzwyczailiśmy się do komunikatów w stylu:

Krytyczna luka WordPressa

które po przeczytaniu szczegółów okazują się:

Krytyczna luka we wtyczce WordPress używanej przez 800 stron.

Tym razem sytuacja jest inna.

Podatność rzeczywiście znajduje się w WordPress Core.

I to w kodzie odpowiedzialnym za jeden z podstawowych mechanizmów systemu – wybieranie szablonu strony.

Błąd był przy tym bardzo niepozorny.

Nie mamy tutaj gigantycznej funkcji wykonującej eval() na danych użytkownika.

Nie mamy jawnego:

  
    include($_GET['file']);
  

Mamy wieloetapową sytuację, w której dane wejściowe są najpierw przetwarzane, później dekodowane, następnie używane do stworzenia nazwy szablonu, a na samym końcu system rozwiązuje ścieżkę pliku.

Każdy z tych etapów osobno może wyglądać niewinnie.

Dopiero ich połączenie tworzy podatność.

I właśnie takie błędy należą do najciekawszych z punktu widzenia bezpieczeństwa aplikacji.

 

Nie panikować, ale też nie odkładać aktualizacji

CVE-2026-87902 jest dobrym przykładem podatności, przy której dwie skrajne reakcje są błędne.

Pierwsza brzmi:

Każda strona WordPress może zostać natychmiast przejęta przez dowolnego użytkownika Internetu.

Nie.

Pełny scenariusz RCE wymaga dodatkowych warunków.

Druga brzmi:

Skoro potrzeba dodatkowych warunków, to nic groźnego.

Również nie.

Atak nie wymaga konta użytkownika.

Podatność znajduje się w Core.

Dotyczy ogromnego zakresu wersji.

Pozwala opuścić oczekiwany obszar katalogów motywu i załadować lokalny plik PHP.

A w odpowiednim środowisku możliwe jest przekształcenie tego mechanizmu w wykonanie kodu.

To wystarczająco dużo powodów, żeby potraktować aktualizację jako pilną.

 

Podsumowanie

CVE-2026-87902 jest krytyczną podatnością mechanizmu rozwiązywania szablonów stron WordPressa.

Problem umożliwia nieuwierzytelnionemu użytkownikowi wykorzystanie nieprawidłowo kontrolowanej ścieżki i – przy spełnieniu odpowiednich warunków – doprowadzenie do załadowania lokalnego pliku PHP znajdującego się poza katalogiem aktywnego motywu.

Podstawowym problemem jest więc Local File Inclusion / Path Traversal .

W określonych środowiskach LFI może zostać wykorzystane jako element łańcucha prowadzącego do Remote Code Execution .

Nie oznacza to, że każda instalacja WordPressa jest automatycznie możliwa do przejęcia. Znaczenie mają między innymi struktura aktywnego motywu, dostępne lokalne pliki PHP, polityka dostępu do systemu plików i konfiguracja środowiska PHP.

Nie zmienia to jednak najważniejszego zalecenia.

Jeżeli administrujesz WordPressem:

zaktualizuj go do wersji zawierającej poprawkę CVE-2026-87902.

Dla aktualnej gałęzi jest to WordPress 7.1.2 , wydany 22 września 2026 roku.

Starsze gałęzie od WordPressa 4.7 również otrzymały wydania zawierające backport poprawki.

W tym przypadku nie chodzi o aktualizację WooCommerce.

Nie chodzi o Elementora.

Nie chodzi o przypadkową wtyczkę.

Problem znajduje się w samym WordPress Core.

I właśnie dlatego aktualizacji tej nie warto odkładać „na później”.