WordPress łata poważne luki w rdzeniu

W ciągu pięciu dni WordPress wydał dwie aktualizacje bezpieczeństwa. Najpierw 7.1.1 z poprawkami dla 11 luk, a chwilę później 7.1.2 z poprawką krytycznej podatności, która w określonych warunkach może doprowadzić do wykonania kodu na serwerze.

Co ważne, nie chodzi o dziurawą wtyczkę czy motyw. Luki znajdują się w samym rdzeniu WordPressa i dotyczą również wielu starszych wersji systemu.

WordPress 7.1.1 – 11 luk bezpieczeństwa

17 września pojawił się WordPress 7.1.1. Aktualizacja zawierała 17 poprawek Core i 11 poprawek bezpieczeństwa.

Jednym z poważniejszych problemów był stored XSS w funkcji wpautop(), znajdującej się w wp-includes/formatting.php.

Atakujący nie potrzebował konta w WordPressie. Odpowiednio przygotowana treść mogła zostać przesłana jako zwykły komentarz. Problem pojawiał się podczas późniejszego przetwarzania i wyświetlania komentarza – WordPress mógł przekształcić jego zawartość w sposób umożliwiający wykonanie skryptu w przeglądarce osoby odwiedzającej stronę.

Atak miał jednak ograniczenie: komentarz musiał zostać opublikowany. Przy standardowych ustawieniach pierwszy komentarz użytkownika zwykle wymaga zatwierdzenia. Jeżeli jednak dana osoba miała wcześniej zaakceptowany komentarz, kolejne mogły zostać opublikowane automatycznie.

Nie była to jedyna poprawka. WordPress 7.1.1 usuwał również m.in. path traversal w kontrolerze szablonów REST API, możliwość nadpisania wpisu przez użytkownika z uprawnieniami Contributor lub wyższymi, ujawnienie adresów szkiców oraz inne problemy z kontrolą uprawnień.

---

Pięć dni później pojawiła się poważniejsza luka

22 września WordPress wydał wersję 7.1.2. Tym razem aktualizacja usuwa tylko jedną podatność – CVE-2026-87902 – ale WordPress określa ją jako krytyczną.

Problem znajduje się w mechanizmie wyboru szablonu strony, w pliku:

wp-includes/template.php

Podczas wyświetlania strony WordPress buduje listę plików szablonów, które może wykorzystać. Jedna ze ścieżek tworzonych na podstawie żądania użytkownika nie przechodziła odpowiedniej kontroli przed przekazaniem jej dalej.

W efekcie niezalogowany użytkownik mógł w określonych warunkach doprowadzić do wczytania lokalnego pliku PHP znajdującego się poza katalogiem aktywnego motywu.

To tzw. Local File Inclusion połączone z path traversal.

Czy można w ten sposób przejąć stronę?

W określonej konfiguracji – tak.

Samo wczytanie lokalnego pliku PHP nie oznacza jeszcze możliwości wykonania dowolnego kodu. Do pełnego RCE, czyli zdalnego wykonania kodu, potrzebne są dodatkowe warunki związane m.in. z konfiguracją serwera, PHP i strukturą używanego motywu.

Dlatego nie każda podatna instalacja WordPressa daje automatycznie możliwość przejęcia serwera.

Nie zmienia to oceny samej luki. Atak nie wymaga zalogowania, a WordPress oficjalnie zakwalifikował podatność jako krytyczną i zalecił natychmiastową aktualizację.

Problem nie dotyczy tylko WordPressa 7.1

To szczególnie ważne w przypadku starszych stron.

Podatność naprawiona w 7.1.2 występuje również w starszych gałęziach WordPressa. Poprawki zostały przygotowane dla kwalifikujących się wersji aż do WordPressa 4.7.

Przykładowo:

• WordPress 7.0 otrzymał poprawkę w 7.0.6,
• WordPress 6.9 w 6.9.9,
• WordPress 6.8 w 6.8.10,
• WordPress 6.7 w 6.7.9,
• WordPress 6.6 w 6.6.9.

WordPress 4.6 i starsze wersje nie otrzymują już takich aktualizacji bezpieczeństwa.

Co zrobić?

Sprawdź wersję WordPressa i zaktualizuj system do najnowszego wydania dostępnego dla swojej gałęzi.

Jeżeli korzystasz z WordPressa 7.1, samo przejście na 7.1.1 już nie wystarczy. Aktualna poprawka bezpieczeństwa znajduje się w 7.1.2.

Przed aktualizacją zrób kopię plików i bazy danych. Po aktualizacji sprawdź przede wszystkim stronę główną, podstrony wykorzystujące własne szablony, logowanie i formularze. W sklepie WooCommerce dodatkowo koszyk, checkout, konto klienta oraz edycję produktów.

Nie traktowałbym wyłączenia komentarzy czy dodatkowego WAF-a jako zamiennika aktualizacji. Pierwsza luka była związana m.in. z komentarzami, ale podatność poprawiona w 7.1.2 znajduje się w zupełnie innym miejscu rdzenia.

Właściwym rozwiązaniem jest aktualizacja WordPress Core.

Jeżeli masz włączone automatyczne aktualizacje bezpieczeństwa, poprawka mogła zostać już zainstalowana. Mimo tego warto wejść w Kokpit → Aktualizacje i sprawdzić faktycznie zainstalowaną wersję.

Źródła

Oficjalny komunikat: WordPress 7.1.1 – Maintenance and Security Release

Lista podatności i wersji z poprawkami: dokumentacja WordPress 7.1.1

Analiza techniczna XSS: Patchstack – WordPress 7.1.1 Security Release

Nowsza poprawka bezpieczeństwa: WordPress 7.1.2 Security Release