WordPress 7.1 – 19 podatności w trzech aktualizacjach, w tym krytyczna luka RCE (CVE-2026-87902)

Gałąź WordPress 7.1 ma dopiero kilka tygodni, a doczekała się już trzech aktualizacji bezpieczeństwa z rzędu: 7.1.1 (17 września), 7.1.2 (22 września) i 7.1.3 (6 października 2026). Łącznie to 19 załatanych podatności — w tym jedna oznaczona przez zespół WordPressa jako krytyczna, możliwa do wykorzystania bez logowania. Jeśli Twoja strona nadal działa na 7.1, 7.1.1 albo 7.1.2, ten wpis jest dla Ciebie.

WordPress 7.1.2 — krytyczna luka bez logowania (CVE-2026-87902)

Zaczynamy od środkowej aktualizacji, bo to ona jest najpilniejsza. WordPress 7.1.2 wyszedł zaledwie pięć dni po 7.1.1 i łata dokładnie jedną podatność (CVE-2026-87902, GHSA-7hp8-65ch-5whp):

• Dołączenie lokalnego pliku PHP przy wyborze szablonu strony — niezalogowany atakujący może w określonych warunkach sprawić, że mechanizm rozstrzygania szablonów załaduje wskazany, czytelny dla serwera plik PHP spoza katalogów aktywnego motywu. Jeśli konfiguracja serwera i aktywny motyw spełniają dodatkowe warunki, prowadzi to do zdalnego wykonania kodu (RCE).

Lukę zgłosił w ramach odpowiedzialnego ujawniania Robert Ressl. W oficjalnym komunikacie zespół WordPressa zaleca natychmiastową aktualizację, a poprawkę zbackportowano do wszystkich gałęzi objętych łatkami bezpieczeństwa — aż do 4.7. To istotna różnica względem sierpniowej luki RCE w 7.0.3: tamta wymagała konta z rolą Autora, ta nie wymaga żadnego konta. Warunki wstępne ograniczają liczbę realnie podatnych stron, ale z zewnątrz nie da się łatwo ocenić, czy Twoja je spełnia — bezpieczniej założyć, że tak.

WordPress 7.1.1 — 11 poprawek bezpieczeństwa

Pierwsza aktualizacja gałęzi 7.1 to — oprócz 36 poprawek błędów — jedenaście łatek bezpieczeństwa. Komunikat WordPress.org wymienia:

• Stored XSS w wpautop() — niezalogowany odwiedzający może wstrzyknąć skrypt przez komentarz (pod warunkiem jego zatwierdzenia).
• HTML API, set_modifiable_text() — sekwencje przedwcześnie zamykające pozwalały „uciec" z komentarza HTML.
• Stored XSS w części motywów obsługujących własne nagłówki (custom headers).
• Instalacja i podgląd nieaktywnego motywu z WordPress.org przez spreparowany adres URL.
• Aktywacja wtyczki „network-only" przez administratora pojedynczej witryny w instalacji multisite.
• Path traversal w kontrolerze szablonów REST API — dla zalogowanych użytkowników.
• Publikacja wpisów customize_changeset przez XML-RPC z pominięciem sprawdzenia uprawnienia edit_css.
• Nadpisanie dowolnego wpisu przez użytkownika z rolą Współpracownika lub wyższą.
• Wyciek tytułu prywatnego wpisu nadrzędnego — brak sprawdzenia read_post w metadanych załącznika.
• Ujawnienie slugów szkiców i wpisów oczekujących — dostępne dla Współpracownika lub wyżej.
• Przepinanie komentarzy (i notatek) pod inny wątek przez dowolnego zalogowanego użytkownika.

Większość z tych luk wymaga jakiegoś konta — ale zwróć uwagę, jak niskiego: Współpracownik to rola, którą często dostają autorzy gościnni i freelancerzy, a „dowolny zalogowany użytkownik" w sklepie WooCommerce oznacza po prostu każdego klienta z kontem.

WordPress 7.1.3 — 7 kolejnych poprawek

Najnowsze wydanie (6 października) to cztery poprawki błędów i siedem łatek bezpieczeństwa, opisanych w komunikacie wydania:

• Nieautoryzowane ujawnienie komentarzy do prywatnych i nieopublikowanych wpisów — bez logowania.
• Stored XSS na stronie Komentarze w panelu administratora, możliwy do wywołania przez komentarz oczekujący na moderację.
• Second-order SQL injection w eksporcie WXR (Narzędzia → Eksport).
• Denial of Service w WP_Http::make_absolute_url().
• XSS w osadzeniach Imgur.
• Możliwość przypinania wpisów (sticky) przez użytkowników z rolą Autora.
• Kolizja nazw akcji w hooku {status}_{type} wynikająca z parametrów, które dało się sfałszować.

Dwie pierwsze pozycje łączy wspólny wektor: komentarze. Atakujący nie potrzebuje konta — wystarczy otwarty formularz komentarzy, a złośliwy kod uruchamia się w przeglądarce administratora, który wchodzi w moderację. To klasyczna droga od „anonimowego gościa" do przejęcia sesji admina.

Co łączy te trzy aktualizacje

W momencie publikacji komunikaty WordPress.org dla wydań 7.1.1 i 7.1.3 nie podają numerów CVE dla poszczególnych poprawek — identyfikatory zwykle pojawiają się w bazach podatności z opóźnieniem. Nie zmienia to faktu, że opis każdej luki i sam kod łatki są już publiczne, więc każdy może porównać wersje i odtworzyć mechanizm ataku. Warto też spojrzeć na listę zgłaszających: obok niezależnych badaczy i zespołu bezpieczeństwa WordPressa pojawiają się zespoły korzystające z narzędzi AI do analizy kodu. Praktyczny wniosek jest prosty — luki są znajdowane szybciej, więc aktualizacje bezpieczeństwa wychodzą częściej, a okno między publikacją łatki a pierwszymi próbami ataków się kurczy. Trzy wydania w niecałe trzy tygodnie to przy takim tempie raczej nowa norma niż wyjątek.

Jak sprawdzić, czy Twoja strona jest podatna

Wersję WordPressa znajdziesz w Pulpit → Aktualizacje. Bezpieczna jest dopiero 7.1.3 — każda wcześniejsza wersja gałęzi 7.1 ma co najmniej siedem znanych, opisanych publicznie luk. Jeśli zostajesz na starszej gałęzi, zainstaluj jej najnowsze wydanie (dla 7.0 to obecnie 7.0.7): poprawki są backportowane do gałęzi aż do 4.7, choć oficjalnie wspierana jest tylko najnowsza wersja, a backporty trafiają tam z opóźnieniem. Dowolną wersję rdzenia możesz sprawdzić w naszej publicznej bazie podatności WordPress (CVE), bez zakładania konta.

Jeśli monitorujesz stronę w MonitorWWW.com, wersja rdzenia jest porównywana z bazą podatności automatycznie — dostajesz alert, gdy zainstalowana wersja ma znaną, niezałataną lukę. Więcej o tym mechanizmie w artykule Krytyczne podatności WordPress (CVE) — nowość w monitoringu.

Jak bezpiecznie zaktualizować

• Zrób pełny backup plików i bazy danych przed aktualizacją.
• Jeśli masz środowisko staging, zaktualizuj najpierw tam i sprawdź motyw, szablony stron oraz formularz komentarzy.
• Zaktualizuj WordPress do wersji 7.1.3 (Pulpit → Aktualizacje → Zaktualizuj teraz). Sprawdź przy okazji, czy automatyczne aktualizacje wydań pomniejszych nie są wyłączone — to one powinny dostarczać takie łatki bez Twojego udziału.
• Jeśli nie możesz zaktualizować od razu, włącz tymczasowo ręczną moderację wszystkich komentarzy (albo wyłącz komentowanie) i przejrzyj listę kont z rolą Współpracownika i Autora — usuń te, których nikt już nie używa.
• Po aktualizacji sprawdź kluczowe funkcje strony: logowanie, komentarze, a w sklepach — koszyk i płatności.

Podsumowanie

Dziewiętnaście podatności w trzech wydaniach, w tym jedna krytyczna bez logowania i kilka kolejnych opartych o zwykły formularz komentarzy — WordPress 7.1 pokazuje, że „zaktualizowałem miesiąc temu" przestało oznaczać „jestem bezpieczny". Przy takim tempie publikowania łatek ręczne śledzenie komunikatów przestaje się skalować, zwłaszcza gdy opiekujesz się więcej niż jedną stroną. Automatyczne porównywanie zainstalowanej wersji z bazą podatności zamienia to w jeden konkretny alert: ta strona, ta wersja, ta luka — zaktualizuj.