WordPress wp2shell (CVE-2026-63030) – krytyczna podatność umożliwiająca zdalne wykonanie kodu (RCE)

WordPress wp2shell – krytyczna podatność RCE w WordPress Core (CVE-2026-63030)

Krytyczna podatność wp2shell w WordPress Core umożliwia zdalne wykonanie kodu bez logowania. Sprawdź podatne wersje, sposób działania ataku oraz jak zabezpieczyć swoją stronę.

21 lipca 2026 • root • PrywatnyInformatyk.pl

W dniu 17 lipca 2026 r. zespół WordPress opublikował pilne aktualizacje bezpieczeństwa eliminujące jedną z najpoważniejszych podatności w historii tego systemu CMS. Luka, określana jako wp2shell, umożliwia zdalne wykonanie kodu (Remote Code Execution – RCE) bez konieczności logowania i bez wykorzystania podatnych wtyczek lub motywów.

Według analizy Wordfence jest to pierwsza od blisko 10 lat krytyczna podatność RCE w samym WordPress Core. Już kilka godzin po opublikowaniu poprawek zaobserwowano pierwsze próby skanowania Internetu oraz wykorzystania podatności.

Na czym polega podatność?

Atak wykorzystuje połączenie dwóch niezależnych podatności:

  • CVE-2026-60137 – SQL Injection w parametrze author__not_in klasy WP_Query.
  • CVE-2026-63030 – błąd typu Route Confusion w endpointzie REST API /wp-json/batch/v1.

Każda z tych podatności osobno ma ograniczony wpływ na bezpieczeństwo. Dopiero ich połączenie pozwala atakującemu przejąć pełną kontrolę nad witryną, utworzyć konto administratora, a następnie uruchomić własny kod PHP poprzez standardowe mechanizmy WordPressa, np. instalację wtyczki.

Podatne wersje

  • WordPress 7.0.0 – 7.0.1 → naprawiono w 7.0.2
  • WordPress 6.9.0 – 6.9.4 → naprawiono w 6.9.5
  • WordPress 6.8.0 – 6.8.5 → podatna na SQL Injection (CVE-2026-60137), naprawiono w 6.8.6

Pełny łańcuch prowadzący do zdalnego wykonania kodu dotyczy wyłącznie gałęzi 6.9.x oraz 7.0.x. Wersja 6.8.x zawiera jedynie podatność SQL Injection.

Czy podatność jest już wykorzystywana?

Tak. Według danych telemetrycznych Wordfence pierwsze próby wykorzystania podatności pojawiły się jeszcze tego samego dnia, w którym opublikowano poprawki bezpieczeństwa. Obecnie publicznie dostępne są również przykładowe exploity (PoC), dlatego administratorzy powinni traktować zagrożenie jako bardzo wysokie.

Co powinien zrobić administrator?

  • Niezwłocznie zaktualizować WordPress do wersji 6.8.6, 6.9.5 lub 7.0.2.
  • Sprawdzić, czy automatyczna aktualizacja została poprawnie wykonana.
  • Zweryfikować listę kont administratorów.
  • Sprawdzić, czy nie pojawiły się nieznane wtyczki lub zmodyfikowane pliki.
  • Przeanalizować logi pod kątem żądań do /wp-json/batch/v1 oraz ?rest_route=/batch/v1.
  • Jeżeli korzystasz z WAF (np. ModSecurity), rozważ tymczasowe blokowanie endpointu /wp-json/batch/v1 do czasu aktualizacji wszystkich instalacji.

Komentarz PrywatnyInformatyk.pl

Podatność jest szczególnie niebezpieczna, ponieważ znajduje się w samym silniku WordPress, a nie w dodatkowej wtyczce. Oznacza to, że nawet świeża instalacja WordPressa, bez żadnych rozszerzeń, może być podatna na atak.

Administratorzy serwerów hostingowych powinni zwrócić szczególną uwagę na ruch kierowany do endpointów REST API oraz monitorować logi pod kątem prób wykorzystania podatności. Samo zastosowanie reguł WAF może ograniczyć ryzyko, jednak jedynym trwałym rozwiązaniem pozostaje aktualizacja WordPressa do wersji zawierającej poprawki bezpieczeństwa.

Źródła