22 września 2026 ukazał się WordPress 7.1.2. To wydanie wyłącznie bezpieczeństwa z jedną poprawką, ale ocenioną jako krytyczna: w określonych warunkach pozwala przejąć stronę bez logowania. Przyszło zaledwie pięć dni po wersji 7.1.1, która łatała jedenaście innych luk. WordPress zaleca aktualizację natychmiast, a większość stron zainstalowała ją sama. Większość, nie wszystkie.
Dlaczego wyszła ta poprawka
Błąd siedział w mechanizmie, który wybiera plik szablonu dla strony. Gdy WordPress szuka szablonu na podstawie adresu strony, sprawdza kilka kandydatów, między innymi plik zbudowany z jej nazwy. Jedna z tych ścieżek nie przechodziła przez funkcję validate_file(), którą WordPress normalnie odsiewa próby wyjścia poza dozwolony katalog.
Efekt: atakujący bez żadnego konta mógł zmusić WordPressa do dołączenia wybranego pliku PHP z serwera, spoza katalogu motywu. W żargonie to lokalne dołączenie pliku (LFI), a przy sprzyjających okolicznościach także zdalne wykonanie kodu (RCE). Luka ma identyfikator CVE-2026-87902, a Patchstack ocenia ją na 9.2 na 10. Zgłosił ją Robert Ressl.
Co jest w changelogu
Changelog jest wyjątkowo krótki:
- jedna poprawka bezpieczeństwa, opisana jako przechodzenie po ścieżkach w wyborze szablonu strony, prowadzące warunkowo do zdalnego wykonania kodu,
- jeden zmieniony plik:
wp-includes/template.php, - żadnych zmienionych pakietów, żadnych nowych funkcji ani poprawek zwykłych błędów.
Według analizy Patchstack poprawka robi dwie rzeczy: dokłada brakujące sprawdzenie validate_file() i wprowadza dodatkową kontrolę, że każdy wybrany szablon faktycznie leży w katalogu motywu. Ta druga zmiana zamyka całą klasę podobnych błędów, nie tylko ten jeden.
Czy Twoja strona była zagrożona
Luka dotyczy wszystkich wersji od 4.7 do 7.1.1, czyli niemal dekady wydań. Ale do poważnego ataku muszą się spotkać dwa warunki naraz.
Warunek pierwszy, motyw. Aktywny motyw (albo motyw nadrzędny) musi mieć w głównym katalogu folder o nazwie zaczynającej się od page-, najczęściej page-templates. Taki folder mają na przykład starsze motywy domyślne, jak Twenty Twelve i Twenty Fourteen, oraz sporo popularnych motywów komercyjnych.
Warunek drugi, serwer. Żeby dołączenie pliku zamieniło się w przejęcie strony, na serwerze musi leżeć odpowiedni plik PHP, który da się w ten sposób wykorzystać. Patchstack wskazuje pearcmd.php z pakietu PEAR przy włączonej opcji PHP register_argc_argv. Ta opcja jest domyślnie włączona m.in. w oficjalnych obrazach Dockera z PHP.
Bez drugiego warunku zostaje samo dołączenie pliku, co nadal jest błędem, ale zwykle nie kończy się przejęciem strony. Ani ogłoszenie WordPressa, ani analiza Patchstack nie wspominają o atakach na żywych stronach, a Patchstack celowo nie publikuje działającego przykładu. To dobry moment, żeby zaktualizować spokojnie, zanim ktoś ten przykład odtworzy.
Aktualizacja szła automatycznie. Dlaczego mogła do Ciebie nie dotrzeć
WordPress sam instaluje wydania bezpieczeństwa na stronach, które mają włączone aktualizacje w tle, i ogłoszenie 7.1.2 mówi to wprost. Poprawkę cofnięto też do wszystkich starszych gałęzi aż do 4.7, więc starsze instalacje dostały własną łatkę.
Pełną listę, aż do 4.7.37, znajdziesz w dokumentacji wydania. Wersje 4.6 i starsze nie dostają już żadnych poprawek.
Automat działa na większości stron, ale znamy kilka typowych powodów, dla których się nie odpalił:
- aktualizacje wyłączono w
wp-config.php: stałaWP_AUTO_UPDATE_COREustawiona nafalsealboAUTOMATIC_UPDATER_DISABLEDnatrueblokuje także łatki bezpieczeństwa, - aktualizacjami zarządza autoinstalator hostingu: wtedy WordPress oddaje mu sterowanie i liczy się to, co jest ustawione w panelu hostingu, nie w WordPressie,
- mało odwiedzana strona albo wyłączony WP-Cron: WordPress sprawdza aktualizacje przy okazji wizyt; jeśli ktoś wyłączył WP-Cron i nie ustawił w zamian zadania na serwerze, sprawdzenie może się nie wykonać,
- brak uprawnień do zapisu plików: WordPress nie podmieni pliku, którego nie może nadpisać,
- instalacja trzymana w repozytorium Git: WordPress celowo nie aktualizuje się sam, jeśli wykryje kontrolę wersji,
- wtyczka, która blokuje aktualizacje: niektóre wtyczki do „zarządzania aktualizacjami” robią dokładnie to.
Co zrobić teraz
1. Sprawdź wersję. Wejdź w Kokpit, Aktualizacje. Jeśli widzisz 7.1.2 albo łatkę swojej gałęzi z tabeli wyżej, jesteś bezpieczny. Jeśli nie, kliknij aktualizację.
2. Sprawdź, czy automat w ogóle u Ciebie działa. W Narzędzia, Zdrowie witryny WordPress ma test aktualizacji w tle. Jeśli zgłasza problem, podaje też przyczynę, zwykle jedną z tych z listy wyżej.
3. Jeśli zarządzasz VPS-em, rzuć okiem na PHP. Sprawdź, czy masz włączone register_argc_argv i czy na serwerze leży PEAR. Po aktualizacji WordPressa ta luka jest zamknięta, ale ta sama para bywa wykorzystywana przy innych błędach tego typu, więc jeśli nie jest Ci potrzebna, lepiej ją wyłączyć.
4. Ustaw to raz, porządnie. U większości stron automat tym razem zrobił robotę sam. Żeby działał także u Ciebie i obejmował wtyczki oraz motywy, a nie tylko rdzeń, przejdź przez nasz poradnik: Jak włączyć automatyczne aktualizacje w WordPress. W sierpniu przy WordPressie 7.0.3 pisaliśmy, że to nie ostatnie takie wydanie. Wrzesień przyniósł dwa w ciągu pięciu dni.
Jeśli nie chcesz pilnować tego sam, na hostingu pod WordPressa aktualizacje i kopie zapasowe przed aktualizacją ustawisz raz z poziomu panelu.
