No to niektórzy właściciele stron na WordPressie mają dziś pilną robotę do wykonania. Właśnie ujawniono krytyczną lukę w samym rdzeniu najpopularniejszego systemu zarządzania treścią, a CERT Polska ostrzega przed masowym atakiem, który może ruszyć w ciągu najbliższych godzin. Nazwana wp2shell (CVE-2026-63030) podatność pozwala przejąć całą witrynę bez logowania, na zwykłej, domyślnej instalacji i bez żadnych dodatkowych wtyczek, a w sieci krąży już gotowy exploit. Poniżej wyjaśniamy, które wersje są zagrożone, jak działa ten atak i jak w pięć minut zabezpieczyć swoją stronę.
Co dokładnie się stało
17 lipca 2026 ujawniono krytyczną podatność w WordPress Core, czyli w samym silniku, na którym stoi ponad 40 procent stron w internecie. Dzień później, 18 lipca, ostrzeżenie wydał CERT Polska (komunikat 124/2026), zapowiadając masowe wykorzystanie luki w ciągu najbliższych godzin.
To nie jest jakaś kolejna dziura we wtyczce. Podatność siedzi w rdzeniu WordPressa, więc dotyczy każdej domyślnej instalacji w zagrożonej wersji, bez względu na to, jakie masz wtyczki czy szablon. Całość ochrzczono nazwą wp2shell, a formalnie składa się z dwóch połączonych błędów:
- CVE-2026-63030, pomylenie tras w endpoincie REST API
/wp-json/batch/v1, - CVE-2026-60137, SQL injection w parametrze
author__not_inzapytania WP_Query.
Efekt połączenia tych dwóch błędów jest najgorszy z możliwych: nieuwierzytelnione zdalne wykonanie kodu (RCE). Napastnik nie musi znać żadnego hasła ani mieć konta, żeby przejąć serwer.
Formalnie luka dostała wynik CVSS 7.5 (poziom wysoki), ale GitHub Security Advisory i CERT Polska opisują ją jako krytyczną, bo skutkiem jest pełne przejęcie strony na zwykłej, domyślnej instalacji. Błąd trasowania batch znalazł Adam Kues z Assetnote, a SQL injection zgłosili niezależnie badacze TF1T, dtro i haongo.
Które wersje są zagrożone
To najważniejsza informacja w całej sprawie. Sprawdź swoją wersję WordPressa, zanim zrobisz cokolwiek innego.
- WordPress 6.9.0 do 6.9.4 oraz 7.0.0 do 7.0.1, pełny łańcuch RCE. Bezpieczne wersje to 6.9.5 i 7.0.2.
- WordPress 6.8.0 do 6.8.5, tu występuje sam SQL injection (CVE-2026-60137). Bezpieczna wersja to 6.8.6.
- WordPress 7.1 beta, załatane w 7.1 beta2.
- Wersje starsze niż 6.8 nie są podatne.
Jeśli nie wiesz, jaką masz wersję, znajdziesz ją w panelu WordPress w prawym dolnym rogu kokpitu albo w Narzędzia, Stan witryny.
Jak działa atak
Endpoint /wp-json/batch/v1 to funkcja WordPressa, która pozwala wysłać wiele żądań do REST API w jednej paczce. Napastnik potrafi tak zmanipulować kolejność żądań w tej paczce, że system gubi przypisanie, które żądanie ma obsłużyć która funkcja. Dzięki temu przesunięciu o jedno miejsce jego żądanie wykonuje się pod innym uchwytem i omija listę dozwolonych tras.
W ten sposób atakujący dociera do podatnego parametru author__not_in. Ten parametr powinien przyjmować listę identyfikatorów, ale jeśli zamiast listy poda się spreparowany tekst, walidacja puszcza go dalej i surowe dane trafiają prosto do zapytania SQL. Stąd już krok do odczytania i modyfikacji bazy danych, a w połączeniu z pierwszym błędem, do wykonania własnego kodu na serwerze bez jednego logowania.
Cała siła tego ataku polega na tym, że nie wymaga niczego specjalnego. Zwykły, świeżo postawiony WordPress w podatnej wersji jest celem.
Czym to grozi
Skuteczne wykorzystanie luki oznacza przejęcie witryny i kradzież danych. Natomiast, w praktyce napastnik może wgrać własny skrypt, tak zwany webshell, i od tej chwili robić z serwerem co chce: podmienić treść, wykraść dane klientów, rozsyłać spam, doinstalować kolejne złośliwe oprogramowanie albo szyfrować pliki dla okupu.
Powaga sytuacji jest tym większa, że w sieci pojawił się już działający proof-of-concept, czyli gotowy przepis na atak. To zwykle sygnał do zautomatyzowanego, masowego skanowania internetu w poszukiwaniu niezałatanych stron. Dokładnie dlatego CERT Polska pisze o spodziewanym masowym wykorzystaniu w ciągu godzin, a nie dni.
Co zrobić teraz (zajmie 5 minut)
- Sprawdź wersję i zaktualizuj. Wejdź w panel WordPress, w Kokpit, Aktualizacje i zainstaluj najnowszą wersję. Celujesz w 6.8.6, 6.9.5 lub 7.0.2 (zależnie od gałęzi, na której jesteś).
- Zweryfikuj, czy aktualizacja faktycznie się wgrała. WordPress.org uruchomił wymuszone automatyczne aktualizacje, ale CERT Polska ostrzega, że w wielu przypadkach one nie zadziałały. Po aktualizacji upewnij się, że numer wersji się zmienił. Dopiero to oznacza, że jesteś bezpieczny.
- Masz kilka stron? Sprawdź każdą osobno. Każda instalacja WordPressa jest podatna niezależnie.
- Nie możesz zaktualizować od ręki? Jako rozwiązanie tymczasowe zablokuj dostęp do ścieżki
/wp-json/batch/v1oraz parametru?rest_route=/batch/v1na poziomie WAF, albo zablokuj całe REST API wtyczką. Pamiętaj, że wyłączenie REST API może zakłócić działanie części funkcji strony, więc traktuj to jako plaster na czas do aktualizacji, a nie docelowe rozwiązanie. Jeśli Twój ruch przechodzi przez Cloudflare, jego reguły WAF blokują oba CVE od 17 lipca, ale i tak zaktualizuj rdzeń.
Jak jesteś chroniony na hostingu HitMe
Ta historia to podręcznikowy przykład, dlaczego liczy się czas reakcji i kilka warstw zabezpieczeń, a nie jedna.
Po pierwsze, automatyczne aktualizacje. Na naszym hostingu masz do dyspozycji AutoInstalator (Installatron), w którym jednym przełącznikiem ustawisz, by WordPress aktualizował się sam, gdy tylko pojawi się nowa wersja. Poprawka bezpieczeństwa taka jak 7.0.2 instaluje się wtedy bez czekania, aż przypomnisz sobie o zalogowaniu do panelu. Więcej o tym piszemy w poradniku Instalacja na hostingu jednym kliknięciem.
Po drugie, warstwa WAF na serwerze. Każdy hosting WordPress w HitMe ma wbudowaną ochronę Imunify360 zintegrowaną z mod_security oraz komercyjne reguły Malware.Expert. To dokładnie ta warstwa, która filtruje ruch aplikacyjny i pomaga blokować próby wykorzystania takich luk jak wp2shell, także zanim zdążysz kliknąć aktualizację. Zaznaczmy uczciwie: WAF skraca okno ekspozycji, ale nie zastępuje łatki. Rdzeń i tak trzeba zaktualizować.
Po trzecie, kopie zapasowe. Nawet w najgorszym scenariuszu, gdyby stronę zdążono zainfekować przed łatką, w każdym pakiecie mamy automatyczne kopie do 14 dni wstecz (plikowe i baz danych), więc możesz przywrócić witrynę do stanu sprzed incydentu.
W skrócie
- Luka: wp2shell (CVE-2026-63030 + CVE-2026-60137) w WordPress Core, nieuwierzytelnione RCE, klasyfikowana jako krytyczna.
- Podatne wersje: 6.9.0-6.9.4 i 7.0.0-7.0.1 (RCE) oraz 6.8.0-6.8.5 (SQL injection). Bezpieczne: 6.8.6, 6.9.5, 7.0.2.
- Realne ryzyko: domyślne instalacje, bez konta i bez wtyczek. Spodziewane masowe ataki, PoC już krąży.
- Co zrobić: zaktualizować rdzeń teraz i zweryfikować, że wersja faktycznie się zmieniła.
- Jak uniknąć powtórki: włączyć automatyczne aktualizacje (Installatron), oprzeć się na warstwie WAF i mieć aktualne kopie zapasowe, wszystko dostępne w hostingu WordPress w HitMe.
Źródła: komunikat CERT Polska 124/2026, ogłoszenie WordPress 7.0.2, analiza Rapid7, rekord CVE-2026-63030.
