Strona, która 17 września przeszła na WordPressa 7.1.1, potrzebuje kolejnej aktualizacji, bo w nowszej wersji 7.1.2 wyszła poprawka luki, której wykorzystanie nie wymaga ani konta, ani kliknięcia administratora. Błąd ma numer CVE-2026-87902 i obejmuje wszystkie wydania od 4.7.0 do 7.1.1. WordPress ocenia go jako krytyczny i zaleca aktualizację od razu. Najgorszy scenariusz, czyli uruchomienie cudzego kodu na serwerze, wymaga jednak zbiegu warunków po stronie motywu i konfiguracji PHP. Dlatego sprawdzamy dwie rzeczy: czy aktualizacja WordPressa już się wgrała i czy twoja strona spełnia te warunki. Aktualizacja z 26 września: luka trafiła 25 września do katalogu podatności wykorzystywanych w atakach, który prowadzi amerykańska agencja CISA. Pierwsze próby ataków firma Patchstack zauważyła kilka godzin po wydaniu poprawki.
Co naprawia WordPress 7.1.2 i od kiedy jest dostępny
Wydanie ukazało się 22 września 2026 roku. Komunikat WordPressa zawiera tylko jedną poprawkę i opisuje ją krótko. Atakujący bez konta może w pewnych warunkach sprawić, że WordPress przy wyborze szablonu strony dołączy wskazany plik PHP spoza katalogów motywu.
Mechanizm da się opowiedzieć bez kodu. Gdy ktoś otwiera podstronę, WordPress szuka pliku szablonu, który ma ją wyświetlić. Jedną z nazw do sprawdzenia składa z fragmentu adresu według wzoru page-{wartość}.php. W podatnych wersjach ta wartość po zdekodowaniu mogła zawierać sekwencję ../, czyli przejście do katalogu wyżej, a WordPress jej nie odrzucał. Odpowiednio przygotowane żądanie wyprowadza go więc poza motyw.
Szczegóły techniczne są w oficjalnym advisory GHSA-7hp8-65ch-5whp, opublikowanym 22 września o 13:57 UTC. Lukę znalazł Robert Ressl i zgłosił ją przez program HackerOne 20 lipca. W dniu wydania łatki opublikował opis i dowód koncepcji, więc sposób ataku jest publiczny.
Firma Patchstack zwraca uwagę na drugą zmianę w wydaniu 7.1.2. Poza załataniem samej ścieżki WordPress dołożył nową kontrolę. Wybrany szablon musi teraz leżeć w katalogu aktywnego motywu, motywu nadrzędnego albo w systemowym katalogu theme-compat. Według Patchstacka to znak, że zespół potraktował problem jako całą klasę błędów, a nie jedną dziurę. To interpretacja firmy, WordPress tego wprost nie napisał.
{ strony www }Strona firmowa, która zbiera zapytania od klientów
Projektujemy strony dla firm na WordPressie: szybkie, wygodne na telefonie i przygotowane pod Google. Pomożemy też napisać treści, które jasno tłumaczą, co sprzedajesz.
Kiedy luka w WordPressie pozwala przejąć stronę: dwa warunki
Liczba opisująca powagę błędu zależy od tego, kto ją liczy i w jakiej skali. WordPress daje 9,2 w skali CVSS 4.0, a w bazie NVD agencja CISA wystawiła 8,1 w starszej skali CVSS 3.1, z adnotacją o wysokiej złożoności ataku. Obie liczby opisują ten sam błąd, tylko inaczej ważą warunki wstępne. Advisory wymienia dwa.
Pierwszy warunek: katalog page- w motywie
Aktywny motyw albo jego motyw nadrzędny musi mieć w głównym folderze katalog, którego nazwa zaczyna się od page-, na przykład page-templates. Advisory wskazuje stare motywy domyślne Twenty Twelve i Twenty Fourteen oraz popularne motywy zewnętrzne, takie jak Neve, Hestia i Sydney. W wersjach obecnych motywów domyślnych od Twenty Twenty-Three do Twenty Twenty-Five, które sprawdził Ressl, takiego katalogu nie było.
Ten warunek jest ważniejszy, niż wynika z części relacji. Według Ressla i analizy Patchstacka bez takiego katalogu opisana ścieżka ataku się urywa, i to już na etapie dołączania pliku. Katalog page-templates jest przy tym zupełnie legalną praktyką, opisaną w dokumentacji motywów, więc jego obecność nie świadczy o żadnym zaniedbaniu autora motywu.
Drugi warunek: plik PHP, który da się wykorzystać
Samo dołączenie pliku uruchamia tylko to, co ten plik już robi. Żeby wykonać własny kod, atakujący potrzebuje na serwerze czytelnego pliku .php, który zachowa się dla niego użytecznie. Najbardziej znanym, choć nie jedynym możliwym kandydatem jest pearcmd.php z pakietu PEAR. Działa w ten sposób przy włączonym ustawieniu PHP register_argc_argv. Advisory pisze wprost, że dotyczy to oficjalnego obrazu php dla Dockera i domyślnej konfiguracji cPanelu przy PHP starszym niż 8.5.
Gdy oba warunki są spełnione, kod wykonuje się z uprawnieniami konta, na którym działa serwer WWW. Ressl pokazał to w laboratorium na WordPressie 7.0.2. Zależnie od uprawnień tego konta atakujący może odczytać konfigurację z hasłem do bazy danych i zmieniać dane strony. Ressl zastrzega, że nie mierzył, jak często oba warunki występują na działających stronach.
Jak sprawdzić, czy twoja strona ma aktualną wersję WordPressa
Poprawka istnieje dla każdej gałęzi od 4.7 w górę, więc nie trzeba przeskakiwać na nową wersję główną.
Gdzie znaleźć numer wersji
Po zalogowaniu wejdź w Kokpit, a potem w Aktualizacje. Ekran pokazuje zainstalowaną wersję i informuje, czy są nowsze. Numer wersji widać też w prawym dolnym rogu każdego ekranu panelu.
Wersje z poprawką dla każdej gałęzi
Lista pochodzi z advisory. Sprawdź dwie pierwsze cyfry swojej wersji i porównaj z odpowiednią pozycją:
- gałęzie 7.x: 7.1.2, 7.0.6
- gałęzie 6.x: 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16
- gałęzie 5.x: 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29
- gałęzie 4.x: 4.9.33, 4.8.32, 4.7.37
Według statystyk WordPress.org z 23 września gałąź 7.1 ma 57 procent instalacji, a niemal cała reszta siedzi na starszych gałęziach, które też dostały poprawkę. Statystyka pokazuje gałąź, nie mówi więc, ile stron już się zaktualizowało. WordPress przypomina też, że w pełni wspierana jest tylko najnowsza wersja, a gałęzie starsze niż 4.7 nie dostają poprawek bezpieczeństwa wcale.
Kto może mieć wyłączone automatyczne aktualizacje
Drobne wydania, czyli konserwacyjne i bezpieczeństwa, WordPress instaluje sam od wersji 3.7. Dokumentacja nazywa wyłączanie tego mechanizmu zdecydowanie niezalecanym. Wyłącza go stała AUTOMATIC_UPDATER_DISABLED albo WP_AUTO_UPDATE_CORE ustawiona na false w pliku wp-config.php. Może to też zrobić filtr we wtyczce albo wykrycie, że pliki strony pochodzą z repozytorium kodu. Wyłączają go też czasem hostingi zarządzane i agencje, które wolą aktualizować ręcznie po testach. Jeśli stronę utrzymuje ktoś inny, zapytaj go wprost o wersję 7.1.2 i datę jej wgrania.
Jak sprawdzić motyw i ustawienia PHP na serwerze
Te dwa sprawdzenia nie zastępują aktualizacji. Mówią tylko, jak blisko najgorszego scenariusza była twoja strona do chwili, gdy poprawka się wgrała.
Motyw sprawdzisz przez menedżer plików w panelu hostingu albo przez FTP. Otwórz wp-content/themes/, a w nim folder aktywnego motywu, i poszukaj katalogu zaczynającego się od page-. Jeśli używasz motywu potomnego, sprawdź też folder motywu nadrzędnego. Nazwę aktywnego motywu podaje zakładka Wygląd, a potem Motywy.
Ustawienie register_argc_argv pokazuje funkcja phpinfo(). Wystarczy tymczasowy plik z jedną linijką kodu otwarty w przeglądarce, który od razu po odczycie trzeba skasować, bo zdradza szczegóły serwera. Można też zapytać o to hosting. Ressl zwraca uwagę na pułapkę: polecenie php -i w terminalu pokazuje konfigurację wiersza poleceń, a strona może działać z inną. Liczy się ta, z której korzysta serwer WWW.
Badacz i Patchstack podają dwa środki, które zmniejszają ryzyko na czas do aktualizacji: wyłączenie register_argc_argv dla żądań WWW i usunięcie nieużywanego pakietu PEAR. Obaj zastrzegają, że żaden z nich nie naprawia samego błędu w WordPressie.
Druga łatka bezpieczeństwa w pięć dni. Co naprawiło wydanie 7.1.1
Wersja 7.1.2 przyszła pięć dni po poprzedniej. WordPress 7.1.1 z 17 września zawierał jedenaście poprawek bezpieczeństwa. Dwie z nich dostały w branży własne nazwy.
Comment2Shell, oznaczony jako CVE-2026-93485, zaczynał się od komentarza anonimowego gościa z ukrytym skryptem. Gdyby zalogowany administrator otworzył stronę z takim komentarzem, skrypt mógł jego sesją wgrać wtyczkę z tak zwanym web shellem, czyli plikiem wykonującym polecenia atakującego. WordPress zastrzegał, że komentarz musiał najpierw zostać zatwierdzony, ale odkrywca opisał sposoby obejścia moderacji. Click2Shell wymagał, żeby administrator kliknął spreparowany link, po czym WordPress sam instalował i podglądał nieaktywny motyw z katalogu.
Obie luki załatała wersja 7.1.1, a 7.1.2 zawiera wszystko, co było w niej. Jedna rzecz nie znika jednak z aktualizacją. Łatka nie cofa zmian, które atakujący zdążył zrobić wcześniej. Jeśli strona ma otwarte komentarze i dostała 7.1.1 z opóźnieniem, przejrzyj listę wtyczek, kont administratorów i plików w poszukiwaniu czegoś, czego nie rozpoznajesz. Jak dobrze potrafi się schować konto dodane przez atakującego, pokazuje późniejsza kampania przez lukę w Ninja Forms, która zostawia ukryte konto administratora.
To już kolejna seria poprawek rdzenia w tym roku. W lipcu opisywaliśmy łańcuch dwóch luk pozwalający przejąć stronę bez logowania, do którego w sierpniu doszła rządowa rekomendacja aktualizacji WordPressa. W sierpniu była też luka w ekranie logowania znaleziona przez system AI. Dla właściciela strony wniosek z tej serii jest praktyczny: automatyczne aktualizacje w tle to dziś podstawowe zabezpieczenie, a ich wyłączenie wymaga kogoś, kto codziennie śledzi komunikaty.
Frontend Master 2026 · Kodożercy
Od pierwszej linijki kodu do deploy
Frontend Master 2026 to pakiet sześciu kursów Kodożerców z HTML, CSS, JavaScriptu i Git. Polskie wideo, prawdziwe projekty, fundamenty, dzięki którym przestajesz trafiać w ciemno.
Sprawdź pakiet →
Najczęstsze pytania
Czy WordPress zaktualizuje się sam do wersji 7.1.2?
W większości przypadków tak, bo automatyczne aktualizacje wydań bezpieczeństwa są w WordPressie domyślnie włączone. Komunikat o wydaniu 7.1.2 zapowiada, że na takich stronach aktualizacja zacznie się sama. Wyjątkiem są strony, na których ktoś ten mechanizm wyłączył. Dlatego numer wersji warto sprawdzić, zamiast go zakładać.
Czy luka w WordPressie jest już wykorzystywana w atakach?
Tak. 25 września agencja CISA dodała CVE-2026-87902 do katalogu aktywnie wykorzystywanych podatności, powołując się na dowody ataków. Firma Patchstack opisała ich przebieg. Pierwszą próbę zablokowała 22 września o 11:49 UTC, kilka godzin po wydaniu poprawki. O 15:34 UTC atakujący próbowali już zapisywać pliki przez pearcmd.php. 23 września w sieci pojawiły się gotowe narzędzia do skanowania i ruch osiągnął szczyt.
Według Patchstacka po udanym ataku w katalogach /tmp i /var/tmp pojawiają się pliki PHP. To między innymi wp-pear-rce-flag.php, poc87902.php albo luci_ z losową końcówką. Firma traktuje ich obecność jako znak, że serwer został przejęty. Jeśli strona po 22 września stała jeszcze na starszej wersji, poproś hosting o sprawdzenie tych katalogów. Sama aktualizacja niczego z nich nie usunie. W tym samym tygodniu poprawkę bezpieczeństwa wydał też Elementor, opisaliśmy ją osobno.
Podsumowanie
Na stronach z włączonymi automatycznymi aktualizacjami poprawka powinna już być zainstalowana, więc pierwszą rzeczą do sprawdzenia jest to, czy ten mechanizm u ciebie działa. Numer wersji w kokpicie rozstrzyga sprawę: 7.1.2 na najnowszej gałęzi albo odpowiednik z listy na starszej. Luka CVE-2026-87902 nie wymaga konta ani kliknięcia administratora. Do dołączenia pliku potrzebny jest katalog page- w motywie, a do wykonania kodu także odpowiedni plik PHP na serwerze. Najbardziej znany wariant to pearcmd.php przy włączonym register_argc_argv. Advisory wymienia wśród zagrożonych motywów popularne Neve, Hestię i Sydney, więc sprawa nie dotyczy wyłącznie starych instalacji. Od 25 września luka jest na liście CISA podatności wykorzystywanych w atakach. Kto aktualizuje strony ręcznie, powinien zrobić to natychmiast. Wersja 7.1.2 zamknie przy okazji luki z wydania 7.1.1. Jeśli strona długo czekała na którąkolwiek z tych łatek, przejrzyj po aktualizacji listę wtyczek i kont administratorów.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
