WordPress 7.1.2 łata krytyczną lukę. Atak bez logowania, podatne wersje od 4.7

W skrócie

22 września 2026 wyszedł WordPress 7.1.2, wydanie bezpieczeństwa z jedną poprawką. Łata ona lukę CVE-2026-87902 w rdzeniu, ocenioną na 9,2 w skali CVSS 4.0, czyli krytyczną. Atakujący nie potrzebuje konta ani żadnej interakcji użytkownika, wystarczy mu publiczny adres strony. Podatne są wszystkie wersje od 4.7.0 do 7.1.1, czyli prawie dziesięć lat wydań. Pełne przejęcie serwera wymaga spełnienia dodatkowych warunków po stronie motywu i konfiguracji PHP, ale spełnia je spora część typowych hostingów. Nie ma obejścia, jedyną naprawą jest aktualizacja. Poprawka została wgrana wstecznie do wszystkich wspieranych gałęzi, więc strona na starym WordPressie też dostanie łatkę bez skoku na 7.1. Niżej znajdziesz opis luki, listę warunków, procedurę sprawdzenia własnej strony i to, czego szukać w logach.

Co zostało załatane

Luka dotyczy mechanizmu, którym WordPress wybiera plik motywu do wyświetlenia strony typu „page". Jeden z parametrów żądania nie przechodził tam sprawdzenia, które zatrzymuje próby wyjścia poza katalog motywu. W efekcie nieuwierzytelniony atakujący mógł zmusić WordPressa do dołączenia dowolnego czytelnego pliku PHP z dysku serwera, także spoza katalogów motywu. Klasa błędu to CWE-98, czyli niewłaściwa kontrola nazwy pliku w instrukcji include.

Samo dołączenie obcego pliku PHP to już poważny problem, bo taki plik wykonuje się z uprawnieniami serwera WWW. Jeśli na serwerze istnieje plik, który przy odpowiednim wywołaniu potrafi wykonać przekazane mu polecenia, z luki robi się zdalne wykonanie kodu, czyli pełne przejęcie strony i wszystkiego, co jest na tym samym koncie hostingowym.

Lukę odkrył i odpowiedzialnie zgłosił Robert Ressl. Poprawka trafiła do WordPressa 7.1.2 i do wszystkich starszych gałęzi, które wciąż dostają łatki, aż do 4.7.

Kiedy strona jest realnie zagrożona

Oficjalne ostrzeżenie i analiza Patchstack wymieniają trzy warunki, które muszą zbiec się razem, żeby atak skończył się wykonaniem kodu. Każdy z nich z osobna jest częsty.

Motyw z katalogiem zaczynającym się od page-. Aktywny motyw, potomny lub nadrzędny, ma w swoim głównym katalogu podkatalog o nazwie zaczynającej się od page-, najczęściej page-templates. Tak zbudowane są stare domyślne motywy Twenty Twelve i Twenty Fourteen oraz popularne motywy komercyjne, między innymi Neve, Hestia i Sydney. Neve i Hestia należą do najpopularniejszych darmowych motywów w katalogu WordPress.org.

Włączona opcja PHP register_argc_argv. To ustawienie interpretera jest domyślnie włączone w oficjalnych obrazach Docker PHP oraz w cPanelu na wersjach PHP niższych niż 8.5. Wiele współdzielonych hostingów w Polsce stoi na cPanelu.

Obecność biblioteki PEAR na serwerze. PEAR instaluje się razem z PHP na większości dystrybucji i w obrazach Docker, więc jej plik wykonywalny zwykle jest na dysku, nawet jeśli nikt go nie używa.

Jeśli Twoja strona spełnia wszystkie trzy warunki, jest w grupie najwyższego ryzyka i aktualizacja powinna być zrobiona dziś. Jeśli nie spełnia któregoś z nich, luka nadal pozwala dołączać pliki z dysku, więc aktualizacja i tak jest obowiązkowa. Warunki mówią tylko o tym, jak blisko najgorszego scenariusza jesteś.

Podatne wersje i numery łatek

Poprawka została wydana dla każdej gałęzi, która wciąż dostaje łatki bezpieczeństwa. Jeśli Twoja strona jest na starszej linii, wystarczy aktualizacja w obrębie tej samej gałęzi, bez skoku na 7.1.

Gałąź	Podatne wersje	Wersja z poprawką
7.1	7.1.0, 7.1.1	7.1.2
7.0	7.0.0 do 7.0.5	7.0.6
6.9	wszystkie	6.9.9
6.8	wszystkie	6.8.10
6.7	wszystkie	6.7.9
6.6	wszystkie	6.6.9
6.5	wszystkie	6.5.12
6.4	wszystkie	6.4.12
6.3	wszystkie	6.3.12
6.2	wszystkie	6.2.13
6.1	wszystkie	6.1.14
6.0	wszystkie	6.0.16
5.x	wszystkie	5.0.29 i odpowiedniki dla 5.1 do 5.9
4.7 do 4.9	wszystkie	4.7.37 i odpowiedniki

Wersje starsze niż 4.7 nie dostają już żadnych poprawek. Strona na takim WordPressie ma znacznie więcej niezałatanych dziur niż ta jedna i wymaga migracji, nie aktualizacji.

Jak sprawdzić swoją stronę w dwie minuty

Trzy sprawdzenia, w kolejności od najważniejszego.

Wersja WordPressa. W kokpicie wejdź w Kokpit -> Aktualizacje. Jeśli widzisz komunikat o dostępnej wersji 7.1.2 lub wersji z tabeli wyżej, strona jest podatna. Przez WP-CLI:

wp core version
wp core check-update

Struktura motywu. Sprawdź, czy aktywny motyw lub jego rodzic ma w głównym katalogu podkatalog zaczynający się od page-:

ls -d wp-content/themes/*/page-*/ 2>/dev/null

Jeśli polecenie coś wypisze, spełniasz pierwszy z trzech warunków.

Ustawienie PHP. Sprawdź stan opcji register_argc_argv w konfiguracji, na której działa strona:

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

Wynik bool(true) oznacza, że spełniasz drugi warunek. Uwaga, wersja PHP z konsoli SSH bywa inna niż ta obsługująca stronę. Pewniejszy wynik daje sekcja Narzędzia -> Stan witryny -> Informacje -> Serwer w kokpicie albo tymczasowy plik z wywołaniem phpinfo(), usunięty zaraz po sprawdzeniu.

Jak zaktualizować

Automatycznie. WordPress domyślnie sam instaluje wydania bezpieczeństwa i drobne aktualizacje. Jeśli nie zmieniałeś tego zachowania, Twoja strona najprawdopodobniej jest już na 7.1.2. Upewnij się w Kokpit -> Aktualizacje albo w mailu, który WordPress wysyła po każdej automatycznej aktualizacji.

Ręcznie z kokpitu. Kokpit -> Aktualizacje -> Zaktualizuj teraz. To wydanie zawiera jedną poprawkę bez zmian w API, więc ryzyko rozjechania wtyczek jest minimalne. Kopia zapasowa przed aktualizacją to i tak dobry nawyk.

Przez WP-CLI. Na jednej stronie:

wp core update
wp core version

Jeśli masz kilkanaście instalacji na jednym koncie, pętla po katalogach załatwia sprawę w minutę:

for d in /home/user/domains/*/public_html; do
  echo "== $d"
  wp --path="$d" core update --minor
done

Przełącznik --minor aktualizuje w obrębie bieżącej gałęzi. Strona na 6.9.8 wskoczy na 6.9.9, a nie na 7.1.2, co pozwala załatać dziurę bez testowania dużej aktualizacji.

Jeśli wyłączyłeś automatyczne aktualizacje. Sprawdź w wp-config.php, czy nie ma tam linii define('WP_AUTO_UPDATE_CORE', false); albo define('AUTOMATIC_UPDATER_DISABLED', true);. Takie ustawienie ma sens tylko wtedy, gdy ktoś regularnie aktualizuje stronę ręcznie. W innym przypadku ustaw wartość 'minor', jak radziliśmy przy okazji wydania 7.0. Duże wersje poczekają na Twoją decyzję, a łatki bezpieczeństwa wejdą same, zwykle w ciągu kilku godzin od publikacji.

Nie możesz zaktualizować od razu

Oficjalny komunikat nie podaje żadnego obejścia i my też go nie zaproponujemy, bo każde jest gorsze od samej aktualizacji. Kilka rzeczy zmniejsza jednak ekspozycję na czas, gdy aktualizacja czeka na okno serwisowe.

• Reguły WAF. Wordfence, Patchstack i większość zapór hostingowych opublikowały reguły blokujące znane wzorce tego ataku w ciągu doby od wydania. Sprawdź, czy Twoja zapora ma aktualne sygnatury.
• Wyłączenie register_argc_argv. W pliku .user.ini lub w panelu hostingu ustaw register_argc_argv = Off. WordPress tego ustawienia nie potrzebuje. To odcina najbardziej znany łańcuch prowadzący do wykonania kodu, ale nie usuwa samej luki.
• Nie zmieniaj nazw katalogów w motywie. Katalog page-templates jest tam po to, żeby motyw znajdował swoje szablony stron. Zmiana nazwy zepsuje układ podstron, a luki nie zamknie w pełni.

Te kroki kupują godziny, nie tygodnie. Aktualizacja pozostaje jedyną naprawą.

Jak sprawdzić, czy ktoś już próbował

W chwili publikacji tego tekstu nie ma publicznych doniesień o atakach na produkcyjne strony. Luka jest jednak prosta, publicznie opisana i dotyczy ogromnej liczby instalacji, więc skanowanie internetu przez boty to kwestia dni, nie tygodni. Warto zajrzeć w logi.

W logu dostępu serwera WWW szukaj żądań do podstron, które zawierają w adresie sekwencje wyjścia poza katalog, czyli ../ w postaci zwykłej albo zakodowanej jako %2e%2e. Na hostingu z Apache lub nginx:

grep -Ei '(\.\./|%2e%2e)' ~/logs/access.log | tail -n 50

Puste wyjście to dobra wiadomość. Trafienia z ostatnich dni oznaczają, że ktoś próbował, choć nie musi to oznaczać, że mu się udało. W takim wypadku sprawdź dodatkowo:

• nowe lub zmienione pliki .php w wp-content/uploads, gdzie kod PHP nie ma prawa się pojawić,
• nieznane konta administratorów w Użytkownicy,
• zmiany w wp-config.php, .htaccess i w plikach motywu w ostatnich dniach, przez find . -newermt '2026-09-20' -name '*.php',
• zadania cron i wtyczki, których nie instalowałeś.

Jeśli cokolwiek z tej listy się potwierdzi, traktuj stronę jako przejętą. Przywróć ją z kopii sprzed 20 września, zaktualizuj rdzeń i zmień wszystkie hasła, łącznie z hasłem do bazy danych i kluczami w wp-config.php. Pełną procedurę hardeningu po incydencie opisaliśmy w checkliście bezpieczeństwa WordPressa.

Piąte wydanie bezpieczeństwa od lipca

To już piąta łatka bezpieczeństwa WordPressa od lipca 2026. Pięć dni wcześniej, 17 września, wyszło 7.1.1 z jedenastoma poprawkami bezpieczeństwa i kilkudziesięcioma poprawkami błędów. Tempo jest wyższe niż w poprzednich latach i nie ma powodu sądzić, że zwolni. Wnioski są dwa. Po pierwsze, automatyczne aktualizacje w obrębie gałęzi powinny być włączone na każdej stronie, która nie ma dedykowanego administratora. Po drugie, wersja PHP ma znaczenie także tu, bo domyślne ustawienia nowszych wydań PHP i nowszych paneli hostingowych są bezpieczniejsze. O tym, którą wersję PHP wybrać, pisaliśmy dwa tygodnie temu.

Źródła

• WordPress 7.1.2 Release, oficjalny komunikat wydania.
• GHSA-7hp8-65ch-5whp, ostrzeżenie bezpieczeństwa z listą podatnych i załatanych wersji oraz wektorem CVSS.
• Patchstack: WordPress 7.1.2 Security Release, analiza techniczna i warunki wykorzystania.
• Help Net Security: CVE-2026-87902, podsumowanie dla administratorów.

Co robimy dla klientów mDiv

Wydanie bezpieczeństwa z oceną 9,2 nie czeka na najbliższy przegląd miesięczny. W ramach opieki nad stroną wydania bezpieczeństwa rdzenia wgrywamy poza zwykłym cyklem, w ciągu godzin od publikacji, po sprawdzeniu, czy nie zmieniają zachowania wtyczek. Kopia zapasowa na osobnym serwerze daje punkt powrotu, gdyby coś poszło nie tak. A jeśli Twój obecny hosting każe siedzieć na starym PHP z domyślnymi ustawieniami sprzed lat, przeniesienie do mDiv jest darmowe.

Jeśli prowadzisz stronę na jednym z wymienionych motywów i nie wiesz, w jakiej wersji jest Twój WordPress, napisz do nas. Sprawdzenie zajmuje kilka minut, a przejęta strona kosztuje zwykle kilka dni.