wp2shell: krytyczna luka w WordPress Core (CVE-2026-63030). Zaktualizuj natychmiast

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_in zapytania 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/v1 oraz parametru ?rest_route=/batch/v1 na 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.