WordPress 7.1.2: Poprawka krytycznej luki w wyborze szablonów stron

Spis treści
WordPress opublikował 22 września 2026 r. wersję 7.1.2 usuwającą lukę sklasyfikowaną jako krytyczna. Projekt zaleca natychmiastową aktualizację i udostępnił poprawki starszym gałęziom aż do 4.7. Przeniesienie poprawki nie oznacza aktywnego wsparcia wszystkich historycznych gałęzi. [1]
Co potwierdza komunikat bezpieczeństwa
CVE-2026-87902 / GHSA-7hp8-65ch-5whp dotyczy wyboru szablonów stron. Przy opisanych warunkach motywu i serwera żądanie bez logowania może spowodować dołączenie dostępnego pliku PHP spoza katalogów motywu, potencjalnie prowadząc do wykonania kodu. W gałęzi 7.1 dotyczy to 7.1.0 i 7.1.1; poprawka znajduje się w 7.1.2. [2]
Zdalne wykonanie kodu oznacza możliwość uruchomienia kodu na serwerze przez atakującego. Warunki mają znaczenie: komunikat nie stwierdza, że każda instalacja została już zaatakowana. Jednocześnie prawidłowo wyglądająca strona główna nie dowodzi zainstalowania poprawki.
Krótka kontrola operacyjna
Przed aktualizacją potrzebna jest kopia plików i bazy danych umożliwiająca odtworzenie witryny. Oficjalna instrukcja opisuje aktualizację przez kokpit i drogę ręczną. [3] Po instalacji zapis rzeczywistej wersji oraz sprawdzenie reprezentatywnych stron daje mocniejszy dowód niż sama informacja o włączeniu aktualizacji automatycznych.
- Zapis wersji każdej instalacji, również środowisk testowych i mniej widocznych witryn.
- Wgranie odpowiedniej oficjalnej wersji bezpieczeństwa i odnotowanie wyniku.
- Kontrola strony głównej, zwykłej strony, wpisu, logowania oraz istotnego formularza.
- Osobna obsługa nieudanych aktualizacji zamiast założenia, że wszystkie zakończyły się poprawnie.
Zakres kontroli sum kontrolnych
Przy dostępnym WP-CLI poniższe polecenia tylko odczytują wersję i porównują pliki rdzenia z opublikowanymi sumami kontrolnymi. --include-root dodatkowo zgłasza nieoczekiwane elementy katalogu głównego. [4]
wp core version
wp core verify-checksums --include-root
Wynik dotyczy plików objętych kontrolą. Nie zastępuje pełnego badania wtyczek, motywów, bazy danych, kont ani wcześniejszych działań. Nieoczekiwane pliki wymagają oceny, a nie automatycznego usunięcia.
Stan redakcyjny: 27 września 2026 r. Wiadomość opisuje wydanie i jego udokumentowany zakres. Nie stwierdza wykorzystania luki na konkretnej stronie ani nie potwierdza bezpieczeństwa danej instalacji.
Pytania i odpowiedzi
Czy wystarczy, że aktualizacje automatyczne w tle są włączone?
Jako oczekiwanie tak, jako dowód nie. Od wersji 3.7 WordPress domyślnie sam instaluje wydania bezpieczeństwa w obrębie gałęzi, takie jak 7.1.2. To, czy w danej instalacji rzeczywiście do tego doszło, zależy jednak od warunków niewidocznych z zewnątrz:
- Stałe
AUTOMATIC_UPDATER_DISABLEDlubWP_AUTO_UPDATE_COREw plikuwp-config.phpalbo filtrauto_update_corewe wtyczce mogą aktualizację wyłączyć lub ograniczyć. - Jeśli w katalogu instalacji lub powyżej znajduje się katalog systemu kontroli wersji, na przykład
.gitlub.svn, WordPress pomija aktualizację automatyczną. - Mechanizm aktualizacji potrzebuje prawa zapisu do plików bez pytania o dane dostępowe FTP; bez niego aktualizacja nie następuje.
- Aktualizację uruchamia WP-Cron. Gdy ustawiona jest stała
DISABLE_WP_CRON, a żadna usługa systemowa nie wywołuje regularniewp-cron.php, aktualizacja nie rusza wcale.
O wyniku WordPress informuje e-mailem wysyłanym na adres administracyjny. Jeśli prowadzi on do skrzynki, której nikt nie czyta, niepowodzenie również pozostaje niezauważone. Dlatego rzeczywiście zainstalowana wersja, zapisana dla każdej instalacji, jest pewniejszym dowodem.
Co oznacza przeniesienie poprawki aż do gałęzi 4.7 dla instalacji na starszej gałęzi?
Instalacja otrzymuje wydanie bezpieczeństwa w obrębie własnej gałęzi i da się ją w ten sposób zabezpieczyć przed tą jedną luką bez przejścia na 7.1. Nic więcej: inne poprawki i prace nad zgodnością nie muszą trafiać wstecz, a oficjalnie utrzymywana jest tylko aktualna wersja. Przeniesienie poprawki daje czas na właściwą aktualizację, ale jej nie zastępuje.
Czy istnieje podobna kontrola sum kontrolnych dla wtyczek?
Tak, polecenie wp plugin verify-checksums --all. Porównuje ono pliki zainstalowanych wtyczek z sumami kontrolnymi, które WordPress.org publikuje dla danej wersji.
Ograniczeniem jest to samo źródło: wtyczki spoza katalogu WordPress.org, na przykład kupione lub napisane samodzielnie, nie mają tam sum kontrolnych, a WP-CLI pomija je z ostrzeżeniem. Motywów polecenie nie obejmuje. Czysty wynik dotyczy więc tylko sprawdzonych wtyczek; dla pozostałych pozostaje porównanie ze znaną, czystą kopią.