Krytyczna luka w rdzeniu WordPressa (WordPress Core) jest już wykorzystywana w atakach, zaledwie kilka godzin po upublicznieniu szczegółów podatności.
Luka oznaczona jako CVE-2026-87902 dotyczy wersji WordPressa sięgających wstecz do gałęzi 4.7 i może umożliwić nieuwierzytelnionemu atakującemu zmuszenie WordPressa do załączenia lokalnego pliku PHP spoza przewidzianych katalogów motywów. Przy określonych konfiguracjach serwera i motywu można to rozszerzyć do zdalnego wykonania kodu (RCE).
WordPress wydał wersję 7.1.2 w dniu 22 września 2026 r., aby usunąć tę lukę, i rozpoczął przenoszenie poprawki do starszych gałęzi objętych wsparciem w zakresie bezpieczeństwa.
Badacze bezpieczeństwa zaobserwowali następnie próby wykorzystania luki, w tym działania zmierzające do nadużycia pliku PHP pearcmd.php w celu zapisania na dysku złośliwych plików PHP.
Dla firm korzystających z WordPressa jest to luka, którą należy traktować jako natychmiastowy priorytet w zakresie aktualizacji.
Czym jest CVE-2026-87902?
CVE-2026-87902 to luka typu path traversal bez uwierzytelniania w mechanizmie rozpoznawania szablonów stron WordPressa.
Błąd tkwi w sposobie, w jaki WordPress przetwarza niektóre ścieżki szablonów stron. Specjalnie spreparowane żądanie może zmanipulować proces rozpoznawania szablonu tak, że WordPress spróbuje załadować plik PHP znajdujący się poza oczekiwanym katalogiem motywu.
Powstaje w ten sposób prymityw lokalnego załączania plików (LFI).
Atakujący nie potrzebuje konta w WordPressie, aby wywołać podatne zachowanie.
WordPress opisuje problem jako możliwość, by nieuwierzytelniony atakujący, w odpowiednich warunkach, spowodował załączenie przez mechanizm rozpoznawania szablonów stron wybranego, odczytywalnego lokalnego pliku PHP spoza katalogów aktywnego motywu. Jeśli spełnione są dodatkowe warunki dotyczące serwera i motywu, może to skutkować RCE.
Jak poważna jest ta luka?
Luka została oceniona następująco:
- CVSS 4.0: 9,2 — krytyczna
- CVSS 3.1: 8,1 — wysoka
- Wymagane uwierzytelnianie: nie
- Wymagana interakcja użytkownika: nie
Różnica między ocenami CVSS wynika z dwóch systemów punktacji, a nie z dwóch różnych luk.
Szczególnie ważny jest brak wymogu uwierzytelniania.
Atakujący nie musi najpierw kraść hasła administratora ani zdobywać konta w WordPressie. Podatne żądanie można wysłać anonimowo.
Jednak nie każda instalacja WordPressa będzie automatycznie podatna na RCE. Komunikat bezpieczeństwa WordPressa wyraźnie zaznacza, że muszą wystąpić odpowiednie warunki dotyczące zarówno środowiska serwera, jak i aktywnego motywu.
Kogo to dotyczy?
Luka dotyczy gałęzi WordPressa sięgających wstecz do wersji 4.7.
WordPress wydał wersję 7.1.2 jako poprawkę dla bieżącej gałęzi 7.1 i przenosi poprawkę bezpieczeństwa do starszych gałęzi, które nadal otrzymują aktualizacje zabezpieczeń.
Badacze bezpieczeństwa udokumentowali, że podatny zakres obejmuje WordPress od 4.7.0 do 7.1.1.
Dla administratorów ważny jest jeden prosty wniosek:
Działanie na WordPressie 7.1.1 nie chroni przed tą luką.
Gałąź 7.1 trzeba zaktualizować do wersji 7.1.2. Starsze obsługiwane gałęzie również należy zaktualizować do odpowiadających im wydań zabezpieczeń.
Jak luka może prowadzić do RCE
Początkowa luka to problem typu path traversal i lokalnego załączania plików.
W podatnym środowisku WordPress można zmanipulować tak, aby załadował plik PHP znajdujący się poza przewidzianym katalogiem motywu.
Staje się to znacznie poważniejsze, gdy atakujący potrafi wskazać na serwerze plik PHP, który można nadużyć do utworzenia lub wykonania treści kontrolowanej przez atakującego.
Badacze zademonstrowali jedną z takich ścieżek, wykorzystującą PEAR i plik pearcmd.php.
Technika ta zależy od dodatkowych warunków środowiskowych, w tym obecności odpowiedniego pliku PHP i konfiguracji PHP umożliwiającej wymaganą obsługę argumentów. Dlatego ścieżka oparta na PEAR nie jest gwarantowana w każdej instalacji WordPressa.
Ważne rozróżnienie z punktu widzenia bezpieczeństwa jest takie:
Sama luka CVE-2026-87902 daje możliwość załączania plików. Ostateczne RCE zależy od tego, czy środowisko zapewnia odpowiedni sposób przekształcenia tej możliwości w wykonanie kodu.
Atakujący zareagowali błyskawicznie
Luka została upubliczniona 22 września 2026 r., gdy WordPress wydał wersję 7.1.2.
Monitoring bezpieczeństwa wykrył następnie próby wykorzystania luki w ciągu kilku godzin.
SecurityWeek, powołując się na Patchstack, poinformował, że pierwsze próby wykorzystania pojawiły się krótko po wydaniu poprawki. Zaobserwowana aktywność koncentrowała się początkowo na rozpoznaniu i wykrywaniu podatności, a następnie przeszła do prób użycia pearcmd.php i zapisywania plików PHP.
Kanadyjskie Centrum Cyberbezpieczeństwa (Canadian Centre for Cyber Security) poinformowało również 23 września, że według doniesień z otwartych źródeł CVE-2026-87902 jest wykorzystywana w atakach.
To szybkie przejście od ujawnienia do wykorzystania jest ważnym ostrzeżeniem dla administratorów WordPressa.
Gdy luka zostanie publicznie opisana, atakujący mogą przeanalizować poprawkę i publicznie dostępne badania, aby opracować techniki skanowania i wykorzystania.
Powiązanie z pearcmd.php
Jednym z najważniejszych elementów prób wykorzystania luki jest plik pearcmd.php, narzędzie PHP związane z PEAR.
Badacze zaobserwowali, że atakujący próbowali użyć luki w WordPressie, aby dotrzeć do tego pliku, a następnie nadużyć jego funkcjonalności do utworzenia treści PHP na serwerze.
Powstały plik PHP może potencjalnie stać się webshellem, dającym atakującemu możliwość wykonywania poleceń przez serwer WWW.
Badacze bezpieczeństwa zaobserwowali to zachowanie w rzeczywistych próbach wykorzystania luki, a nie tylko w demonstracjach laboratoryjnych.
Firmy nie powinny jednak zakładać, że sama obecność pearcmd.php oznacza, że serwer został przejęty.
Pełny łańcuch wykorzystania zależy od kilku warunków, w tym od podatnej wersji WordPressa, struktury motywu, uprawnień systemu plików i konfiguracji PHP.
Dlaczego ten atak jest szczególnie niepokojący
Kilka czynników sprawia, że CVE-2026-87902 jest istotna.
🔴 Logowanie nie jest wymagane
Atakujący nie potrzebuje danych uwierzytelniających WordPressa, aby dotrzeć do podatnej funkcjonalności.
🔴 Luka w rdzeniu
Problem występuje w rdzeniu WordPressa, a nie w pojedynczej wtyczce zewnętrznej.
🔴 Duża historyczna powierzchnia ataku
Podatny kod istnieje w gałęziach WordPressa sięgających wstecz do wersji 4.7.
🔴 Publiczne badania nad wykorzystaniem luki
Analiza techniczna i materiały proof-of-concept pojawiły się krótko po ujawnieniu, co obniża barierę dla atakujących tworzących zautomatyzowane skanery.
🔴 Możliwość wykonania kodu
W odpowiednich warunkach prymityw załączania plików może przerodzić się w zdalne wykonanie kodu z uprawnieniami dostępnymi dla serwera WWW.
Co powinni zrobić administratorzy WordPressa
✅ Zaktualizuj WordPressa natychmiast
Najważniejszym działaniem jest zainstalowanie odpowiedniego wydania zabezpieczeń.
W przypadku bieżącej gałęzi 7.1 oznacza to aktualizację do:
WordPress 7.1.2
Starsze obsługiwane gałęzie należy zaktualizować do odpowiedniego wydania zabezpieczeń zawierającego poprawkę CVE-2026-87902.
Nie czekaj na kolejne okno serwisowe, jeśli możesz bezpiecznie zaktualizować wcześniej.
✅ Sprawdź, czy automatyczne aktualizacje zostały ukończone
WordPress obsługuje automatyczne aktualizacje zabezpieczeń, ale firmy nie powinny zakładać, że każda instalacja zaktualizowała się pomyślnie.
Sprawdź faktycznie zainstalowaną wersję na każdej produkcyjnej witrynie.
Jest to szczególnie ważne w przypadku:
- zarządzanych instalacji WordPressa
- witryn skierowanych do klientów
- starszych witryn
- witryn deweloperskich wystawionych do internetu
- witryn zarządzanych przez zewnętrznych dostawców
✅ Przejrzyj logi serwera WWW
Ponieważ próby wykorzystania luki zaobserwowano krótko po ujawnieniu, administratorzy powinni przejrzeć logi HTTP i serwera WWW pod kątem podejrzanych żądań związanych z nietypowymi ścieżkami szablonów stron lub próbami dostępu do lokalnych plików PHP.
Szukaj aktywności w okolicach 22 września 2026 r. i później, zwłaszcza w systemach, które nie zostały szybko załatane.
✅ Poszukaj nieoczekiwanych plików PHP
Jeśli podatna witryna była wystawiona po publicznym ujawnieniu luki, sprawdź katalogi z prawem zapisu pod kątem nieoczekiwanych plików PHP.
Szczególną uwagę należy zwrócić na niedawno utworzone pliki w lokalizacjach tymczasowych lub związanych z przesyłaniem plików.
Nie zakładaj automatycznie, że każdy nieznany plik PHP jest złośliwy; zbadaj jego pochodzenie i czas utworzenia, zanim usuniesz ślady.
✅ Sprawdź aktywność webshella
Jeśli podejrzewasz wykorzystanie luki, sprawdź witrynę pod kątem:
- nieoczekiwanych plików PHP
- nowych kont administratorów WordPressa
- zmodyfikowanych wtyczek lub motywów
- nieoczekiwanych zaplanowanych zadań
- zmian w
wp-config.php - nieznanych połączeń wychodzących
- zmodyfikowanych plików
.htaccess - nieoczekiwanych zmian w plikach rdzenia
Udane zainstalowanie webshella może pozwolić atakującemu utrzymać dostęp nawet po załataniu samego WordPressa.
✅ Zmień dane uwierzytelniające, jeśli podejrzewasz włamanie
Jeśli dowody wskazują, że atakujący uzyskał możliwość wykonania kodu, samo zaktualizowanie WordPressa nie wystarczy.
Firmy powinny rozważyć zmianę:
- haseł administratorów WordPressa
- danych dostępowych do hostingu
- danych dostępowych FTP/SFTP
- kluczy SSH
- danych dostępowych do bazy danych
- kluczy API
- danych dostępowych do chmury, dostępnych z serwera
Dochodzenie powinno ustalić, jakie informacje były potencjalnie dostępne, zanim zostanie określony pełny zakres rotacji danych uwierzytelniających.
Firmy powinny też przejrzeć swoje środowisko PHP
Łańcuch wykorzystania luki z użyciem pearcmd.php pokazuje, dlaczego bezpieczeństwo serwera bazowego ma znaczenie.
Firmy powinny sprawdzić:
- zainstalowane komponenty PHP
- konfigurację PHP
- uprawnienia do plików
- katalogi z prawem zapisu
- uprawnienia serwera WWW
- uprawnienia do wykonywania PHP
- czy zainstalowano zbędne narzędzia
- obrazy kontenerów i obrazy bazowe
Luka w WordPressie nie powinna automatycznie dawać atakującemu nieograniczonej kontroli nad serwerem bazowym.
Silne uprawnienia systemu plików i izolacja aplikacji mogą znacząco zmniejszyć skutki udanego ataku.
Dlaczego załatanie rdzenia WordPressa nie wystarcza
Bezpieczne wdrożenie WordPressa wymaga wielu warstw ochrony.
Firmy powinny połączyć:
Aktualną wersję WordPressa
↓
Bezpieczną konfigurację PHP
↓
Ograniczone uprawnienia systemu plików
↓
Zaporę aplikacji internetowych (WAF)
↓
Segmentację sieci
↓
Monitorowanie punktów końcowych i serwerów
↓
Scentralizowane rejestrowanie zdarzeń i alertowanie
Takie warstwowe podejście jest szczególnie ważne w przypadku instalacji WordPressa dostępnych publicznie.
Jeśli atakującemu uda się wykorzystać lukę w aplikacji internetowej, dodatkowe mechanizmy kontroli powinny zapobiec przerodzeniu się włamania w pełne przejęcie serwera.
Szersza lekcja z zakresu cyberbezpieczeństwa
CVE-2026-87902 pokazuje, jak szybko atakujący mogą zareagować na nowo ujawnioną lukę.
Sekwencja zdarzeń była wyjątkowo krótka:
Ujawnienie luki → wydanie poprawki → publiczna analiza techniczna → zautomatyzowane sondowanie → aktywne wykorzystanie
Taki cykl staje się coraz powszechniejszy.
Atakujący nie muszą już koniecznie poświęcać miesięcy na opracowanie technik wykorzystania luk. Gdy poprawka i analiza techniczna zostaną upublicznione, zespoły ds. bezpieczeństwa powinny zakładać, że szybko może nastąpić zautomatyzowane skanowanie.
To, że CVE-2026-87902 jest luką w rdzeniu WordPressa, sprawia również, że szerokie skanowanie jest szczególnie praktyczne.
WordPress zasila ogromną liczbę witryn, co oznacza, że jeden podatny komponent rdzenia może dać atakującym dużą populację potencjalnych celów.
Podsumowanie
CVE-2026-87902 to poważna luka w WordPressie, ale szczegóły techniczne mają znaczenie.
Nieprawdziwe jest twierdzenie, że każda podatna instalacja WordPressa automatycznie umożliwia RCE bez uwierzytelniania. Podstawowa wada to path traversal / lokalne załączanie plików bez uwierzytelniania, natomiast RCE wymaga dodatkowych warunków w motywie i środowisku serwera.
To, co zostało potwierdzone, w zupełności wystarcza, aby uzasadnić natychmiastowe działanie: WordPress wydał wersję 7.1.2 właśnie po to, aby usunąć ten problem, a badacze bezpieczeństwa zaobserwowali już próby wykorzystania luki w atakach.
Gdy krytyczna luka w rdzeniu WordPressa zostaje upubliczniona, liczy się szybkość aktualizacji. Zaktualizuj natychmiast, sprawdź, czy aktualizacja się powiodła, i przeanalizuj logi oraz pliki, jeśli witryna pozostawała narażona po ujawnieniu luki.
