WordPress 7.1.4 łata 22 luki. Sprawdź, czy strona już się zaktualizowała

WordPress.org opublikował 28 października 2026 o 18:13 czasu polskiego wersję 7.1.4. To wydanie wyłącznie bezpieczeństwa: według opisu wersji w dokumentacji WordPressa usuwa 22 podatności, a zespół WordPressa zaleca aktualizację natychmiast. Większość stron zaktualizuje się sama, ale lepiej to sprawdzić, niż zakładać.

Co zrobić

Wystarczy wejść w kokpicie strony w Kokpit → Aktualizacje (Dashboard → Updates) i sprawdzić, czy strona ma już wersję 7.1.4 (albo poprawioną wersję swojej starszej gałęzi, o czym niżej). Jeśli tak, nic więcej nie trzeba robić.

Jeśli nie, aktualizację można uruchomić ręcznie z tego samego ekranu, najlepiej po zrobieniu kopii zapasowej. Według komunikatu WordPress.org strony obsługujące automatyczne aktualizacje w tle zaczną ją same. Ręcznego sprawdzenia wymagają przede wszystkim strony z wyłączonymi aktualizacjami automatycznymi oraz strony, którymi zarządza agencja, firma hostingowa lub zewnętrzny panel – wtedy warto zapytać opiekuna, czy 7.1.4 już jest.

Starsze wersje WordPressa

Poprawki trafiły też do wszystkich starszych gałęzi, aż do 4.7. Razem z 7.1.4 wyszły wersje 7.0.8, 6.9.11, 6.8.12, 6.7.11 i 6.6.11, a jeszcze tego samego wieczoru (28 października) WordPress.org udostępnił też paczki dla gałęzi 6.5 i starszych, od 6.5.14 do 4.7.39. Wszystkie są na liście wydań WordPressa i WordPress oferuje je stronom w aktualizacjach automatycznych, więc strona na starszej gałęzi dostanie poprawkę dla swojej wersji. Dokumentacja wersji 7.1.4 podaje, ile z 22 luk dotyczy każdej gałęzi: 7.0 i 6.9 wszystkich, 6.5 – 17, 5.0 – 6, a 4.7 – dwóch.

WordPress 4.6 i starsze nie dostają już żadnych poprawek. WordPress.org przypomina też, że aktywnie wspierana jest tylko najnowsza wersja, więc pozostawanie na starej gałęzi to tymczasowe rozwiązanie, a nie plan.

Co naprawia wersja 7.1.4

Najbardziej nietypowa poprawka dotyczy samego procesu aktualizacji. Według WordPress.org wyścig (race condition) podczas aktualizacji rdzenia mógł w czasie jej trwania prowadzić do zdalnego wykonania kodu. Sam WordPress nie opisuje warunków ataku. Według analizy Patchstack atakujący nie potrzebuje żadnego konta, ale musiałby trafić z żądaniem w kilkusekundowe okno, gdy trwa aktualizacja, a katalog wp-content/upgrade/ musiałby być dostępny z internetu. W tym czasie leży w nim rozpakowana kopia WordPressa z instalatorem pod przewidywalną nazwą; wersja 7.1.4 dodaje do niej losowe znaki. Patchstack ocenia, że w praktyce trudno to wykorzystać, i radzi dodatkowo zablokować na serwerze dostęp do wp-content/upgrade/ oraz sprawdzić, czy katalog nie wyświetla listy plików.

Większość pozostałych poprawek to luki typu stored XSS, czyli możliwość zapisania na stronie złośliwego skryptu, który uruchamia się potem w przeglądarce innego użytkownika, na przykład administratora. Dotyczą m.in. Interactivity API, kilku bloków (m.in. Kategorie, paginacja komentarzy, linki nawigacji wpisów) i Customizera. Według listy poprawek większość z nich wymaga konta z rolą Współtwórca (Contributor) lub wyższą, niektóre – Autor albo Redaktor.

Wydanie naprawia też ujawnianie niepublikowanych zmian z Customizera niezalogowanym odwiedzającym, dostęp ról moderujących komentarze do notatek (Notes) przy wpisach, których nie mogą edytować, oraz aktualizuje wbudowane certyfikaty główne po wycofaniu zaufania do eMudhra. Dwie luki zgłosiło Anthropic.

Kogo dotyczy najbardziej

Skoro większość luk wymaga zalogowanego konta, najbardziej narażone są strony, na których konta ma wiele osób: serwisy redakcyjne, blogi z gościnnymi autorami, strony z otwartą rejestracją i sklepy. Strona z jednym kontem administratora jest mniej narażona na tę część poprawek, ale niepublikowane zmiany z Customizera mogli zobaczyć także niezalogowani, a luka w procesie aktualizacji według Patchstack nie wymaga żadnego konta. Aktualizacja dotyczy więc każdej strony.

WordPress.org nie podał numerów CVE ani ocen powagi poszczególnych luk. Numerów CVE nie miały też 29 października w południe wpisy o tych lukach w bazie WPScan. Ani WordPress.org, ani Patchstack nie informują, by którakolwiek z luk była wykorzystywana w atakach. W przeciwieństwie do lipcowego wydania 7.0.2 komunikat nie wspomina też o wymuszonej aktualizacji, więc strony z wyłączonymi aktualizacjami automatycznymi pozostaną na starej wersji, dopóki ktoś ich nie zaktualizuje.