Spis treści 4 sekcji
  1. Czym jest wp2shell
  2. Dlaczego to problem konkretnie na AWS
  3. Wymuszona aktualizacja to nie jest gwarancja - zweryfikuj
  4. Plan działania krok po kroku
TL;DR: 17 lipca 2026 WordPress wydał awaryjne wersje 7.0.2 i 6.9.5, które łatają wp2shell (CVE-2026-63030) - krytyczną lukę pozwalającą przejąć witrynę zdalnie, bez logowania. Podatne są wersje 6.9.0-6.9.4 oraz 7.0.0-7.0.1. Najważniejsze: zaktualizuj rdzeń do 7.0.2 lub 6.9.5 i upewnij się, że łatka faktycznie weszła - nie zakładaj z góry, że automatyczna aktualizacja się wykonała.

WordPress to najpopularniejszy silnik stron internetowych na świecie - napędza znaczną część sieci, także tej polskiej. Postawisz go praktycznie wszędzie, również na AWS: od jednoklikowego blueprintu na Lightsail po własny serwer na EC2 (jak w naszym poradniku migracji WordPressa na AWS). Dlatego luka w samym rdzeniu WordPressa to nie jest problem niszowy - dotyczy ogromnej liczby witryn naraz, a naprawa jest prosta i pilna.

Czym jest wp2shell

wp2shell (oznaczenie CVE-2026-63030, ocena CVSS 7.5) to luka w samym rdzeniu WordPressa - nie we wtyczce, nie w motywie. Badacze z Searchlight Cyber, którzy ją zgłosili, opisują ją jako łańcuch błędów w REST API (konkretnie w endpointcie batch), prowadzący do zdalnego wykonania kodu (RCE). Kluczowe i najgroźniejsze jest jedno słowo: pre-auth. Atakujący nie potrzebuje żadnego konta, hasła ani interakcji użytkownika - wystarczy anonimowe żądanie HTTP do podatnej witryny.

Dlaczego to jest poważne: RCE bez uwierzytelnienia to najwyższa półka zagrożeń. Udany atak oznacza pełną kontrolę nad witryną: wstrzyknięcie backdoora, kradzież danych, podmianę treści, wykorzystanie serwera do dalszych ataków. Skala jest duża, bo podatna jest domyślna instalacja - bez żadnej egzotycznej konfiguracji. Searchlight celowo nie opublikował szczegółów technicznych ani gotowego exploita, żeby dać administratorom czas na łatanie - ale zakłada się, że publiczny kod ataku pojawi się szybko.

Podatne wersje to 6.9.0-6.9.4 oraz 7.0.0-7.0.1. Wersje starsze niż 6.9 nie są podatne - luka pojawiła się dopiero w kodzie gałęzi 6.9, która trafiła do wydania w grudniu 2025. Łatki to 7.0.2 oraz 6.9.5, obie wydane 17 lipca 2026.

Dlaczego to problem konkretnie na AWS

Tu wraca fundamentalna zasada chmury - model współodpowiedzialności. Na EC2 i Lightsail AWS odpowiada za sprzęt, hypervisor i sieć, ale za system operacyjny, aplikację i jej łatanie odpowiadasz Ty. Amazon nie zaktualizuje za Ciebie WordPressa na Twojej instancji. To samo dotyczy warstwy bezpieczeństwa: AWS WAF czy GuardDuty mogą wykryć lub spowolnić atak, ale nie załatają dziury w kodzie. Jeśli chcesz ugruntować ten temat, mamy osobny artykuł o bezpieczeństwie i modelu współodpowiedzialności AWS.

Jest jeszcze niuans, który stawia self-hostowane WordPressy na AWS w pierwszej linii ognia. Według badaczy podatna ścieżka jest osiągalna, gdy witryna nie używa trwałego object cache (Redis lub Memcached). A to jest domyślny stan zdecydowanej większości pojedynczych instalacji na jednej instancji EC2 czy na Lightsailu - trwały object cache to element, który dokłada się świadomie, zwykle dopiero przy większym ruchu i z osobną warstwą danych lub ElastiCache. Innymi słowy: typowy WordPress "postawiony i zapomniany" na AWS jest dokładnie w tej konfiguracji, którą luka lubi najbardziej.

Warto wiedzieć: brak trwałego object cache nie jest zaproszeniem, żeby go szybko włączyć jako "obejście". Object cache to optymalizacja wydajności, a nie zabezpieczenie - opieranie ochrony na jego obecności to kruchy fundament. Jedyną prawdziwą naprawą jest aktualizacja rdzenia do 7.0.2 lub 6.9.5.

Wymuszona aktualizacja to nie jest gwarancja - zweryfikuj

Domyślnie WordPress ma włączone automatyczne aktualizacje w tle dla wydań bezpieczeństwa, a przy tej luce WordPress.org dodatkowo wymusza aktualizację dla podatnych instalacji, które mają auto-update włączony. Brzmi jak "problem rozwiązał się sam". W praktyce na serwerach, którymi zarządzasz sam - a EC2 i Lightsail to dokładnie takie serwery - automatyczna aktualizacja potrafi po cichu nie wykonać się. Najczęstsze powody:

  • Uprawnienia i właściciel plików - użytkownik serwera WWW nie ma prawa zapisu do plików rdzenia (częste po ręcznej migracji lub na stackach Bitnami z Lightsaila).
  • Wyłączone w konfiguracji - stałe DISALLOW_FILE_MODS lub WP_AUTO_UPDATE_CORE ustawione w wp-config.php blokują samodzielną aktualizację.
  • Metoda zapisu przez FTP - gdy WordPress ma skonfigurowane FS_METHOD na FTP bez poprawnych danych, aktualizacja utyka.
  • Brak miejsca na dysku - pełny wolumen EBS to cicha śmierć każdej aktualizacji.
  • Zablokowany ruch wychodzący - restrykcyjna grupa bezpieczeństwa lub NACL, przez którą instancja nie dosięga api.wordpress.org.

Wniosek jest prosty i jest esencją podejścia SecOps: nie ufaj założeniom, sprawdź stan faktyczny. Zweryfikuj realnie działającą wersję rdzenia na każdej witrynie, zamiast zakładać, że "przecież się aktualizuje".

Plan działania krok po kroku

  1. Zinwentaryzuj. Znajdź wszystkie WordPressy pod swoim kontem AWS - instancje EC2, Lightsaile, kontenery. Łatwo zapomnieć o tej jednej starej witrynie klienta, która stoi od trzech lat.
  2. Sprawdź wersję każdej. Najpewniej przez WP-CLI (wp core version), alternatywnie w panelu administracyjnym lub w pliku readme.html w katalogu WordPressa.
  3. Załataj do 7.0.2 lub 6.9.5. Preferuj WP-CLI albo panel administracyjny. To jest jedyna prawdziwa naprawa.
  4. Zweryfikuj, że łatka faktycznie weszła. Po aktualizacji ponownie sprawdź numer wersji - nie kończ na kliknięciu "aktualizuj". Możesz też użyć bezinwazyjnego checkera wp2shell.com udostępnionego przez Searchlight.
  5. Nie możesz od razu załatać? Zablokuj endpoint. Jako tymczasowe obejście zablokuj na warstwie brzegowej dostęp do /wp-json/batch/v1 oraz ?rest_route=/batch/v1 - regułą w AWS WAF, w konfiguracji Nginx/Apache albo na CloudFront.
  6. Przejrzyj logi. Poszukaj żądań POST do endpointu batch sprzed aktualizacji, sprawdź findingi w GuardDuty, nietypowe procesy i nowe pliki w wp-content/uploads.
  7. Podejrzewasz kompromitację? Potraktuj instancję jako skażoną. Sama "aktualizacja na wierzchu" nie usuwa backdoora - rotuj sekrety i odtwórz witrynę z czystego, znanego dobrego obrazu.
Pro tip - stopgap na AWS WAF: jeśli witryna jest za AWS WAF, dodaj własną regułę Block dopasowującą URI zawierające /wp-json/batch/v1 lub query string z rest_route=/batch/v1. Gotowe managed rules dla WordPressa pomagają, ale własna, precyzyjna reguła na ten konkretny endpoint jest pewniejsza do czasu wgrania łatki. Pamiętaj: to kupuje czas, nie zastępuje aktualizacji.

Czy to dotyczy WordPressa na Lightsail?

Tak. Lightsail najczęściej uruchamia WordPressa z blueprintu Bitnami, który jest zwykłą instalacją rdzenia WordPressa - podlega tej samej luce. Co więcej, stacki Bitnami mają własny układ uprawnień i ścieżek, przez który automatyczna aktualizacja bywa wyłączona lub nie wykonuje się tak, jak na typowym hostingu. Sprawdź wersję ręcznie i nie zakładaj, że Lightsail zrobił to za Ciebie.

Mam włączone automatyczne aktualizacje - czy jestem bezpieczny?

Nie automatycznie. Na serwerach, którymi zarządzasz sam (EC2, Lightsail), automatyczna aktualizacja potrafi po cichu nie wykonać się z powodu uprawnień do plików, ustawień w wp-config.php, braku miejsca na dysku czy zablokowanego ruchu wychodzącego. Jedyny pewny sposób to zweryfikować realnie działającą wersję rdzenia - musi być 7.0.2 lub 6.9.5.

Czy AWS mnie przed tym ochroni?

Nie w warstwie aplikacji. W modelu współodpowiedzialności łatanie WordPressa na EC2 i Lightsail należy do Ciebie, nie do AWS. Usługi takie jak AWS WAF czy GuardDuty mogą pomóc wykryć lub spowolnić atak, ale nie naprawią luki w kodzie WordPressa. Naprawa to aktualizacja rdzenia.

Nie mogę teraz zaktualizować - co robić w międzyczasie?

Zablokuj dostęp do endpointu batch API (/wp-json/batch/v1 oraz ?rest_route=/batch/v1) na warstwie brzegowej - w AWS WAF, w reverse proxy Nginx/Apache albo na CloudFront. To tymczasowe obejście, które kupuje czas. Zaplanuj aktualizację najszybciej jak to możliwe, bo obejście nie usuwa samej luki.

Jak sprawdzić, czy witryna nie została już zaatakowana?

Przejrzyj logi serwera pod kątem żądań POST do endpointu batch sprzed aktualizacji, sprawdź listę kont administracyjnych, nowe lub zmodyfikowane pliki (szczególnie w wp-content/uploads), nieznane zadania cron oraz findingi w GuardDuty. Jeśli cokolwiek budzi wątpliwości, traktuj instancję jak skażoną i odtwórz ją z czystego obrazu.
Emil Kowalczyk

Pasjonat chmury i twórca CloudManiak.pl. Na co dzień MSP Engineer w amerykańskiej firmie ClearScale (AWS Premier Tier Partner). Pomagam osobom wchodzącym do świata chmury zdobywać wiedzę i certyfikaty.