WordPress 7.1.3: łatka na błąd czekający w kolejce komentarzy
WordPress 7.1.3: siedem łatek bezpieczeństwa, w tym błąd czekający w kolejce komentarzy
6 października 2026 WordPress.org opublikował wersję 7.1.3 — wydanie opisane jako „maintenance and security release”, czyli serwisowo-bezpieczeństwowe. Łata siedem błędów bezpieczeństwa i cztery pomyłki w kodzie rdzenia. Poprawki trafiły do wszystkich wspieranych starszych gałęzi, więc problem dotyczy nie tylko najnowszej wersji, ale szerokiego zakresu aktywnych instalacji WordPressa.
Najgłośniejszy z siedmiu błędów to przechowywany XSS na ekranie moderacji komentarzy, zgłoszony przez badacza z Trail of Bits. Mechanizm jest nieprzyjemny: złośliwy skrypt można umieścić w treści komentarza czekającego w kolejce „do zatwierdzenia”, i nic się nie dzieje, dopóki administrator albo moderator nie otworzy tego ekranu w panelu. Dopiero wtedy kod się wykonuje — w kontekście konta z uprawnieniami do zarządzania treścią. Łatwo to przeoczyć, bo atakujący nie musi nigdzie się logować — wystarczy, że zalogowany administrator wykona rutynową czynność, jaką jest przegląd komentarzy do moderacji.
Pozostałe sześć poprawek jest mniej spektakularnych, ale warto je znać. Drugi pod względem istotności błąd to SQL injection drugiego rzędu w eksporcie WXR — uruchamia się tylko wtedy, gdy administrator sam wykona eksport treści, więc ryzyko jest ograniczone, ale nie zerowe na stronach, gdzie eksport robi się rutynowo przy migracjach. Dalej jest błąd uprawnień pozwalający kontu z rolą Autora przypinać posty na stronie głównej, nieuwierzytelnione ujawnianie treści komentarzy z postów prywatnych i nieopublikowanych, XSS przy osadzaniu obrazków z Imgura, odmowa usługi w funkcji odpowiedzialnej za przetwarzanie adresów URL oraz drobny problem z parametrem w jednym z haków rdzenia. WordPress nie opublikował na razie numerów CVE ani ocen w skali CVSS dla żadnego z tych siedmiu zgłoszeń, a jak dotąd nie ma potwierdzonych przypadków wykorzystania w praktyce.
Ciekawy jest też szczegół organizacyjny: trzy z siedmiu błędów zgłosił Anthropic. To pokazuje, że duże firmy AI coraz częściej przepuszczają kod open source — w tym rdzeń WordPressa — przez własne narzędzia do audytu bezpieczeństwa, zanim ktokolwiek inny zdąży to zrobić w złych intencjach.
Co z tym zrobić. Większość hostingów stosuje automatyczne aktualizacje „minor” w ciągu kilku godzin od wydania, więc spora część stron jest już załatana bez żadnej akcji właściciela. Warto jednak zajrzeć do Kokpit → Aktualizacje w panelu WordPressa i sprawdzić numer wersji. Jeśli widzisz coś starszego niż 7.1.3 albo odpowiedni patch w starszej gałęzi, zaktualizuj od razu, zamiast czekać na kolejny cykl automatu. Jeśli zarządzasz kilkoma stronami na hostingu, który nie włącza automatycznych aktualizacji rdzenia domyślnie, to jest dokładnie ten moment, żeby to sprawdzić ręcznie. Sama łatka nie wymaga zmiany konfiguracji serwera ani wtyczek — to czysto kwestia wersji rdzenia.
Tego typu wydania nie mierzymy bezpośrednio w naszych testach wydajności czy czasu odpowiedzi — metodologię tych pomiarów opisujemy na stronie o tym, jak testujemy i stronie o tym, jak liczymy wyniki — ale higiena aktualizacji rdzenia to dokładnie ten rodzaj rzeczy, który odróżnia hosting zajmujący się tym za użytkownika od takiego, który tego nie robi.
