Przejdź do treści
🛡️ Gdyby Twoja strona została dziś w nocy zhakowana, kto zauważyłby to pierwszy: Ty czy Twoi klienci? Nowość: bezpieczeństwo CyberEX dla stron klientów EvoEX, bezpłatnie. Dowiedz się więcej →🛡️ Gdyby Twoja strona została dziś w nocy zhakowana, kto zauważyłby to pierwszy: Ty czy Twoi klienci? Nowość: bezpieczeństwo CyberEX dla stron klientów EvoEX, bezpłatnie. Dowiedz się więcej →🛡️ Gdyby Twoja strona została dziś w nocy zhakowana, kto zauważyłby to pierwszy: Ty czy Twoi klienci? Nowość: bezpieczeństwo CyberEX dla stron klientów EvoEX, bezpłatnie. Dowiedz się więcej →
Panel klienta

Wybierz język

Kontakt
← Wszystkie artykuły
Cyberbezpieczeństwo

Luka w WordPress CVE-2026-87902: krytyczna poprawka,

WordPress haavatavus CVE-2026-87902: kriitilised parandused,

Luka jest śledzona jako CVE-2026-87902, a zespół ds. bezpieczeństwa WordPress ocenił ją na 9.2 punktu na 10 w skali CVSS v4. Oznacza to krytyczny poziom zagrożenia, niską złożoność ataku oraz brak konieczności uwierzytelniania lub interakcji ze strony użytkownika.

22 września WordPress wydał wersję 7.1.2, która usuwa krytyczną lukę w zabezpieczeniach, pozwalającą nieuwierzytelnionemu atakującemu sprawić, by oprogramowanie załadowało wybrany przez niego plik PHP z miejsca znajdującego się poza katalogami aktywnego motywu. W określonych konfiguracjach serwera i motywu atakujący może również doprowadzić do wykonania kodu na serwerze.

Co jest uszkodzone

Luka znajduje się w funkcji rdzenia WordPress, która odpowiada za wybór właściwego pliku szablonu podczas renderowania strony. Błąd tkwi w funkcji get_page_template(), której WordPress używa do wyboru pliku motywu renderującego stronę. Atakujący może przekierować to wyszukiwanie na czytelny plik .php w innym miejscu na serwerze.

To błąd typu path traversal (przejście po ścieżce): żądanie wychodzi poza katalog, w którym kod powinien pozostać, a WordPress następnie włącza ten plik, natomiast PHP wykonuje znajdujący się w nim kod.

Badacz bezpieczeństwa Robert Ressl, który odkrył lukę i zgłosił ją prywatnie przez program HackerOne, wyjaśnia, że głównym problemem jest lokalne włączenie pliku PHP przez nieuwierzytelnione żądanie frontendowe.

W udowodnionym przez niego łańcuchu od włączenia pliku do wykonania dowolnego kodu PHP wykorzystano komponenty PEAR, które były już dostępne w testowanym środowisku serwerowym. PEAR nie jest zależnością WordPress, dlatego ta ścieżka nie jest dostępna w każdym wdrożeniu. Oznacza to, że faktyczne wykonanie kodu (RCE) nie jest gwarantowane w każdej witrynie, ale samo włączenie pliku jest możliwe praktycznie wszędzie tam, gdzie luka nie została załatana.

Niezależne badanie bezpieczeństwa potwierdza mechanizm prostszymi słowami:

atakujący wysyła anonimowe żądanie z dwiema publicznymi wartościami, pagename i page_id. page_id wskazuje na faktycznie opublikowaną stronę, więc WordPress obsługuje ją normalnie. Wartość pagename, zawierająca podwójnie zakodowane przejście po katalogach, pozostaje w żądaniu.

Których wersji dotyczy problem

Projekt WordPress uznaje za podatne wszystkie wersje od 4.7.0 do 7.1.1, czyli praktycznie niemal wszystkie dziś używane instalacje WordPress, które nie zostały w porę zaktualizowane.

Poprawka

Poprawka jest dostarczana w wersji 7.1.2 oraz w 24 starszych gałęziach, od 7.0.6 aż do 4.7.37. Witryny, które akceptują automatyczne aktualizacje w tle, zaktualizują się same, natomiast pozostałe muszą wykonać aktualizację w panelu administracyjnym, w sekcji „Aktualizacje”.

Zespół ds. bezpieczeństwa WordPress podkreśla, że ponieważ jest to wydanie bezpieczeństwa, witryny zaleca się zaktualizować niezwłocznie.

Sytuacja jest szczególnie pilna, ponieważ luka jest już wykorzystywana w praktyce. Firma zajmująca się bezpieczeństwem Patchstack informuje, że próby ataków zaobserwowano już w dniu publikacji poprawki, a pierwszą aktywność odnotowano 22 września 2026 r. o godz. 17:44 UTC. Oznacza to, że między publicznym ujawnieniem a pierwszymi próbami ataków minęło zaledwie kilka godzin.

Co zrobić teraz

  1. Zaktualizuj WordPress do wersji 7.1.2 (lub odpowiedniego wydania bezpieczeństwa dla starszej gałęzi) natychmiast – to najważniejsze działanie.
  2. Jeśli natychmiastowa aktualizacja nie jest możliwa, rozważ środki łagodzące na poziomie serwera, zgodnie z zaleceniami badaczy bezpieczeństwa, np. reguły typu WAF/RapidMitigate.
  3. Sprawdź logi serwera i WordPress pod kątem nietypowych żądań zawierających parametr pagename z zakodowanymi znakami przejścia po ścieżce.
  4. Upewnij się, że automatyczne aktualizacje w tle są włączone, aby w przyszłości szybciej eliminować podobne incydenty.

Uwaga: ten artykuł opisuje lukę wyłącznie w celach informacyjnych i obronnych, na podstawie publicznie dostępnych raportów bezpieczeństwa. Nie zawiera kroków ani kodu służącego do wykorzystania luki.

Źródła:

Gotowy, by zacząć swój projekt?

Opowiedz nam o swoim pomyśle — wyślemy Ci e-mailem propozycję terminu rozmowy wideo, aby omówić szczegóły i przygotować wycenę.