22 września WordPress wydał aktualizację 7.1.2, łatającą krytyczną lukę w samym rdzeniu systemu — CVE-2026-87902 z oceną 9.2 w skali CVSS. Nie minęło kilka godzin od publikacji, a atakujący zaczęli skanować internet w poszukiwaniu podatnych instalacji. To podręcznikowy przykład tego, jak krótko dziś trwa okno bezpieczeństwa między łatką a pierwszym realnym atakiem — i dlaczego “zaktualizuję w weekend” to dziś zbyt duże ryzyko, szczególnie dla systemu, który napędza ponad jedną trzecią stron internetowych na świecie.
Na czym polega błąd
Podatność siedzi w funkcji get_page_template(), odpowiedzialnej za dobór szablonu strony. Napastnik, wysyłając odpowiednio spreparowany parametr pagename z zakodowaną sekwencją %2e%2e (czyli „../”), potrafi ominąć mechanizm oczyszczania danych wejściowych. WordPress dekoduje ten ciąg dopiero na etapie ustalania szablonu, co pozwala wskazać dowolny czytelny plik PHP leżący poza katalogiem aktywnego motywu — na przykład pearcmd.php, standardowy skrypt PEAR obecny na wielu serwerach współdzielonych.
Tu zaczyna się właściwy atak: wykorzystując ustawienie register_argc_argv, napastnik przekazuje polecenia powłoki przez parametry zapytania do pearcmd, co pozwala zapisać złośliwy plik PHP w katalogu /tmp lub /var/tmp. Efekt końcowy to zdalne wykonanie kodu bez jakiegokolwiek logowania. Do skutecznego ataku potrzebne są dwa warunki: aktywny motyw musi mieć katalog zaczynający się od „page-” (np. page-templates) oraz na serwerze musi istnieć wspomniany, czytelny plik PEAR — a to na współdzielonym hostingu z PHP jest bardzo częste.
Błyskawiczna eksploatacja
Według danych firm Patchstack i Previdian pierwsze próby ataku zarejestrowano już o 11:49 UTC w dniu publikacji łatki — najpierw jako sondowanie plików rdzenia typu wp-links-opml.php. Następnego dnia atakujący przeszli już do właściwych prób zapisu plików przez pearcmd, a w sieci pojawiły się gotowe szablony do narzędzia Nuclei, co gwałtownie zwiększyło skalę automatycznych skanów. Do tej pory odnotowano ponad 68 prób ataku z adresów IP m.in. z New Jersey i Indonezji, obejmujących instalowanie web shelli i rekonesans serwerów.
Kogo dotyczy problem
Luka dotyczy wersji WordPressa od 4.7.0 aż do 7.1.1 — praktycznie każdej instalacji, która przez lata nie była systematycznie aktualizowana. Poprawki trafiły do wersji 7.1.2, 7.0.6, 6.9.9 i 6.8.10, a backport bezpieczeństwa przygotowano nawet dla wiekowej gałęzi 4.7.37. Skala jest ogromna: WordPress napędza według różnych szacunków ponad 40% wszystkich stron internetowych, a duża część z nich to sklepy, blogi firmowe i strony wizytówkowe zarządzane przez firmy hostingowe i freelancerów, którzy nie zawsze mają wdrożone automatyczne aktualizacje.
Co zrobić już teraz
Jeśli zarządzasz stroną lub serwerem WordPress, najważniejsza jest natychmiastowa aktualizacja do wersji 7.1.2 (lub odpowiedniego backportu dla starszych gałęzi) — większość hostingów pozwala zrobić to jednym kliknięciem z panelu. Jeśli aktualizacja z jakiegoś powodu nie jest od razu możliwa, warto tymczasowo zablokować na poziomie WAF-a lub serwera zapytania zawierające sekwencje %2e%2e i %252e%252e w parametrze pagename, a także wyłączyć w php.ini opcję register_argc_argv, która jest kluczowa dla drugiego etapu ataku. Dobrze też sprawdzić katalog /tmp i /var/tmp pod kątem nieznanych plików PHP oraz zweryfikować, czy używany motyw ma katalog zaczynający się od „page-”. Administratorzy wielu instalacji WordPress — a tacy w Polsce obsługują dziesiątki, jeśli nie setki stron klientów — powinni potraktować tę łatkę priorytetowo i nie czekać na cykliczny przegląd.
Podsumowanie
CVE-2026-87902 to kolejny dowód na to, że w przypadku popularnego, otwartoźródłowego oprogramowania czas reakcji na krytyczną poprawkę bezpieczeństwa liczy się w godzinach, nie dniach czy tygodniach. Unikanie logowania, gotowe skanery i publicznie dostępne szablony ataku sprawiają, że luka o ocenie 9.2 zamienia się w realne zagrożenie dla milionów stron praktycznie z dnia na dzień. Jeśli prowadzisz stronę na WordPressie albo zarządzasz nią dla klientów, sprawdź wersję już teraz — to kilka minut, które mogą uchronić przed przejęciem całego serwera.
źródło: https://thehackernews.com/2026/09/attackers-exploit-wordpress-cve-2026.html