Aktualizacja WordPressa. Rząd wydał rekomendację

Jeśli twoja strona stoi na WordPressie i od połowy lipca nikt przy niej nie majstrował, masz dziś jedno zadanie do odhaczenia. Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa wydał rekomendację dotyczącą podatności w tym systemie i zaleca niezwłoczną aktualizację wszystkich działających instalacji. Dokument powstał w konsultacji z CSIRT NASK, CSIRT GOV i CSIRT MON. Poprawki wyszły 17 lipca, więc zalecenie przychodzi trzy tygodnie po nich. Sama luka nie jest nowa. Nowe jest to, że państwo uznało za potrzebne o niej przypomnieć.

Co dokładnie zaleca Pełnomocnik Rządu

Dokument wymienia dwie podatności, CVE-2026-63030 w usłudze REST API oraz CVE-2026-60137, i podaje cztery zalecenia. Rekomendacja jest skierowana do podmiotów krajowego systemu cyberbezpieczeństwa i tak też ją opisuje sam dokument. Nikt nie każe robić tego samego właścicielowi bloga o pieczeniu chleba, ale lista działa równie dobrze na każdej stronie:

• zaktualizować wszystkie instalacje WordPressa do rekomendowanych wersji,
• przejrzeć logi pod kątem podejrzanych zapytań do REST API,
• ograniczyć dostęp do ścieżki /wp-json/batch/v1 oraz do parametru ?rest_route=/batch/v1,
• postawić przed stroną zaporę aplikacyjną, czyli filtr odsiewający złośliwe zapytania, zanim dojdą do WordPressa.

W dokumencie pada zdanie, że możliwość wystąpienia incydentu krytycznego została potwierdzona. To ocena ryzyka, a nie komunikat o tym, że gdzieś w Polsce już do czegoś doszło. Autorzy nie podają żadnego przykładu zaatakowanej instytucji ani liczby podatnych stron.

Które wersje WordPressa są bezpieczne

Poprawione wydania podatnych gałęzi to 7.0.2, 6.9.5 i 6.8.6. Wyszły 17 lipca w jednym wydaniu bezpieczeństwa, każde dla swojej gałęzi. Numerów wersji nie ma w rekomendacji rządowej, pochodzą z ogłoszenia samego projektu WordPress. Jeśli masz WordPressa z gałęzi 6.8, 6.9 albo 7.0 w starszym wydaniu, aktualizacja WordPressa jest do zrobienia dzisiaj, a nie w wolnej chwili. Wydania wcześniejsze niż 6.8 tych dwóch podatności nie mają.

Projekt opisał wtedy dwa problemy. Pierwszy to ułatwione wstrzyknięcie kodu SQL, czyli podsunięcie bazie danych własnego zapytania. Drugi to pomylenie tras w zbiorczym punkcie REST API połączone z tym samym rodzajem wstrzyknięcia, prowadzące do zdalnego wykonania kodu. Firmy bezpieczeństwa nazwały to połączenie wp2shell. Według ich opracowań na wersjach od 6.9.0 do 7.0.1 obie luki zestawione razem pozwalają nieuwierzytelnionemu napastnikowi wejść przez adres /wp-json/batch/v1 i uruchomić własny kod. Gałąź 6.8 dotyczy wyłącznie pierwszej z nich. Krótko mówiąc: nie trzeba było mieć konta na stronie, żeby ją przejąć. Więcej o samym mechanizmie napisaliśmy w tekście o krytycznej luce w WordPressie.

Dlaczego rekomendacja przychodzi trzy tygodnie po łatce

Zespół WordPress.org nie czekał na dobrą wolę administratorów. Dla stron z podatnymi wersjami włączył wymuszone aktualizacje przez wbudowany mechanizm automatycznych aktualizacji. Mimo to na początku sierpnia strona rządowa uznała, że temat wymaga osobnego pisma.

Automatyczne aktualizacje da się wyłączyć i w firmowych instalacjach bywają wyłączone. Czasem z rozsądku, bo strona ma wtyczki, które przy podbiciu wersji potrafią się wysypać. Czasem dlatego, że stroną zajmowała się agencja, z którą umowa skończyła się dwa lata temu. Efekt jest ten sam: łatka istnieje, tylko nie dojechała. Ten wzorzec widzieliśmy niedawno przy lukach w Quick.CMS, których producent nie zamierzał naprawić – z tą różnicą, że tam poprawki w ogóle nie było.

Do tego kod dowodowy, czyli gotowy przykład wykorzystania luki, trafił do publicznych repozytoriów w ciągu godzin od ujawnienia. Firmy bezpieczeństwa opisywały próby wykorzystania w swoich pułapkach badawczych już w kolejny weekend. Przy takim tempie trzy tygodnie to bardzo długo.

Frontend Master 2026 · Kodożercy

Zrozum, co się dzieje pod spodem twojej strony

Frontend Master 2026 to sześć kursów Kodożerców z HTML, CSS, JS i Git. Z fundamentami przestajesz kopiować bez zrozumienia, zaczynasz świadomie poprawiać, łączyć i rozszerzać każdy projekt.

Zobacz program →

Zabezpieczenie WordPressa poza samą aktualizacją

Zacznij od sprawdzenia numeru wersji, bo bez tego reszta jest wróżeniem. Znajdziesz go w kokpicie, w sekcji Aktualizacje. Jeśli numer się zgadza z jedną z trzech poprawionych wersji, najpilniejsza część jest za tobą.

Potem zostają trzy rzeczy z listy Pełnomocnika. Przegląd logów serwera może pokazać, czy pojawiały się podejrzane zapytania do REST API. Pewności nie da, bo zapis bywa niepełny. Ograniczenie dostępu do zbiorczego punktu REST API zamyka drogę wykorzystania opisaną w analizach tych podatności. Zapora aplikacyjna bywa dostępna w panelu hostingu, ale nie w każdym pakiecie i nie u każdego dostawcy.

Jedna uwaga na koniec tej listy. Zabezpieczenie WordPressa nie jest czynnością jednorazową i nikt tego nie załatwia jednym kliknięciem. Aktualizacja usuwa same podatności, ale rekomendacja obejmuje też audyt logów, ograniczenie dostępu i zaporę. Za miesiąc wyjdzie kolejna podatność i pytanie brzmi, czy wtedy ktokolwiek zauważy.

Podsumowanie

Trzy numery wersji zamykają sprawę po stronie kodu: 7.0.2, 6.9.5 i 6.8.6, wydane 17 lipca 2026. Rekomendacja Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa z 5 sierpnia dokłada trzy działania, które warto wykonać nawet po aktualizacji. Przejrzeć logi zapytań do REST API, ograniczyć dostęp do zbiorczego punktu tego interfejsu i włączyć zaporę aplikacyjną. Dokument nie mówi o żadnym incydencie w polskiej instytucji, mówi o potwierdzonej możliwości jego wystąpienia. Najważniejsze pytanie nie dotyczy jednak tej luki, tylko tego, kto w twojej organizacji odpowiada za sprawdzenie, czy strona w ogóle dostaje aktualizacje. Jeśli odpowiedź brzmi “chyba agencja”, to jest właśnie rzecz do wyjaśnienia w tym tygodniu.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.