WordPress 7.1.4 – 22 podatności naprawione, w tym luka RCE w procesie aktualizacji

28 października 2026 zespół WordPressa wydał wersję 7.1.4. To wydanie bezpieczeństwa, które łata 22 podatności. Najpoważniejsza to race condition podczas aktualizacji rdzenia, który może prowadzić do zdalnego wykonania kodu (RCE). Reszta to głównie luki XSS, w tym kilka w nowym Interactivity API. WordPress zaleca natychmiastową aktualizację. Sprawdź, czy Twoja strona nie została już zaktualizowana automatycznie, bo to wydanie jest przeznaczone także dla automatycznych aktualizacji w tle.

Najważniejsze: race condition przy aktualizacji rdzenia

Zespół opisuje to jako wyścig (race condition) podczas aktualizacji rdzenia, który może prowadzić do RCE. Zgłosił go Umut Bayram. Oficjalny komunikat nie podaje numeru CVE ani wymaganych uprawnień, a opis w pierwszym komunikacie mówi o „oknie aktualizacji". Zmiany w kodzie dotyczą m.in. plików class-wp-upgrader.php i update-core.php. Nie ma więcej szczegółów technicznych, więc oceniaj to ostrożnie: potraktuj lukę jako poważną, dopóki nie ma pełnego opisu.

W przeciwieństwie do krytycznej luki z 7.1.2 (CVE-2026-87902) tu nie ma potwierdzonej możliwości ataku bez logowania, ale też nie ma potwierdzenia, że takiej możliwości nie ma. Aktualizacja jest jedynym rozsądnym krokiem.

Pozostałe poprawki

Poniżej lista z oficjalnej strony wydania. Komunikat WordPress.org łączy część z nich w grupy, a oficjalna liczba to 22.

Wymagające konta Współpracownika (Contributor) lub wyższego

• Stored XSS przez białe znaki w ogranicznikach bloków (Rafie Muhammad, Awesome Motive).
• Stored XSS w selektywnym odświeżaniu Customizera (Rafie Muhammad).
• Stored XSS przez adresy javascript: w powiązaniach Interactivity API (Luis Herranz i inni zgłaszający).
• Stored XSS przez powiązania obsługi zdarzeń w Interactivity API (Jon Surrell).
• Stored XSS przez prototype pollution w przestrzeniach nazw kontekstu Interactivity API (rekter0).
• Stored XSS i odmowa usługi (DoS) w powiązaniach Interactivity API (rekter0, Marcel Karlsson, Jon Surrell, Alex Concha).
• Elementy object w powiązaniach Interactivity API mogą ładować strony administracyjne (rekter0).
• Stored XSS w etykietach bloków „Następna/Poprzednia strona komentarzy" i „Link nawigacji wpisów" (Alex Concha, zespół bezpieczeństwa WP).

Wymagające konta Autora lub Redaktora

• Autor+: stored XSS w Interactivity Router przez wgrane pliki tekstowe (Anas Cherni).
• Redaktor+: stored XSS na ekranie żądań usunięcia danych osobowych (zgłosiło Anthropic).

Bez podanego poziomu uprawnień lub inne

• Niepublikowane zmiany w Customizerze widoczne dla niezalogowanych odwiedzających (ujawnienie informacji, Antonio Lorensius Silaban).
• Wstrzyknięcie ciągu formatującego w bloku „Kategorie", prowadzące do XSS (Ben Bidner).
• Własne role z uprawnieniami moderacji komentarzy mogły czytać, edytować i usuwać notatki do wpisów, których nie mogą edytować (Ramon, zespół bezpieczeństwa WP).
• Treść wpisu mogła przesłaniać dane modułu skryptowego przez pasujący identyfikator elementu (Weston Ruter).
• Utwardzenie: nieescapowane nazwy użytkowników na ekranach „Użytkownicy sieci" w multisite (zgłosiło Anthropic) oraz niebezpieczne zamiany preg_replace() w blokach Obraz i Playlista (Ben Bidner).
• Aktualizacja wbudowanych certyfikatów głównych po unieważnieniu certyfikatu eMudhra. To nie jest błąd w kodzie WordPressa.

Pełna lista jest w dokumentacji wydania 7.1.4, a komunikat w WordPress.org News. Numery CVE nie zostały podane w tych dokumentach, więc ich tu nie wymieniamy.

Kogo dotyczy i które wersje są poprawione

WordPress zbackportował poprawki do wszystkich gałęzi objętych łatkami bezpieczeństwa, a wciąż aktywnie wspierana jest tylko najnowsza wersja. Liczba dotkniętych luk zależy od wersji:

WordPress 4.6 i starsze nie dostają już łatek bezpieczeństwa. Na takich wersjach nie ma czego aktualizować w ramach tej samej gałęzi, trzeba przejść na nowszą.

Dlaczego warto to potraktować poważnie, choć większość to XSS

• Stored XSS od poziomu Współpracownika to nie jest „tylko XSS". Na stronach z wieloma autorami, z otwartą rejestracją albo z gośćmi piszącymi wpisy atakujący może wykonać skrypt w przeglądarce administratora i przejąć konto.
• Interactivity API to nowa część rdzenia i ta aktualizacja łata w niej aż kilka błędów. Warto śledzić kolejne wydania.
• Luka w procesie aktualizacji dotyczy mechanizmu, który ma Cię chronić. Takie błędy traktuj z najwyższą uwagą.

Jak bezpiecznie zaktualizować

• Zrób pełny backup plików i bazy danych poza serwerem produkcyjnym.
• Wejdź w Pulpit → Aktualizacje → Zaktualizuj teraz. Strony, które mają włączone automatyczne aktualizacje w tle, zaktualizują się same. Sprawdź wersję w stopce panelu administracyjnego.
• Jeśli masz staging, zaktualizuj najpierw tam i sprawdź motyw, bloki, formularze i panel administratora.
• Do czasu aktualizacji ogranicz konta Współpracowników i Autorów do osób, którym ufasz.
• Po aktualizacji sprawdź logowanie, edytor bloków, formularz komentarzy, a w sklepach koszyk i płatności.
• Pamiętaj o PHP: sam WordPress nie naprawi luk PHP2Shell. Tu potrzebna jest osobna aktualizacja na serwerze.

Następne planowane wydanie to WordPress 7.2 (8 grudnia 2026). Wersję rdzenia możesz sprawdzić w naszej publicznej bazie podatności WordPress (CVE), bez zakładania konta.

Podsumowanie

WordPress 7.1.4 to czwarte wydanie bezpieczeństwa gałęzi 7.1 w niecałe sześć tygodni (7.1.1 do 7.1.4). Najważniejsza jest luka w aktualizacji rdzenia, ale większość pozostałych poprawek to XSS dostępne dla zwykłych autorów. Zaktualizuj do 7.1.4, albo do poprawionej wersji swojej gałęzi, a potem upewnij się, że nikt nie dodał nowych kont administratorów ani nieznanych plików.

Źródła

• WordPress.org: WordPress 7.1.4
• WordPress.org: dokumentacja wersji 7.1.4
• GBHackers: WordPress 7.1.4 Security Update