Krytyczne luki wp2shell pozwalają przejąć stronę WordPress. Ataki już trwają

WordPress wydał awaryjne aktualizacje usuwające podatności CVE-2026-60137 i CVE-2026-63030. Połączenie obu luk, nazwane wp2shell, może umożliwić niezalogowanemu napastnikowi wykonanie kodu na serwerze i całkowite przejęcie strony. Badacze potwierdzili rzeczywiste ataki, instalowanie webshelli oraz tworzenie trwałego dostępu.

WordPress opublikował pilną aktualizację

17 lipca 2026 roku zespół WordPressa udostępnił wersję 7.0.2. Aktualizacja usuwa jeden problem krytyczny oraz jeden problem wysokiego ryzyka.

Ze względu na powagę zagrożenia WordPress włączył wymuszone automatyczne aktualizacje dla podatnych instalacji. Nie należy jednak zakładać, że każda strona została poprawnie zaktualizowana — automatyczny proces może zostać przerwany przez konfigurację hostingu, brak miejsca, nieprawidłowe uprawnienia albo wcześniejsze wyłączenie aktualizacji.

WordPress zaleca natychmiastowe wdrożenie poprawki. Oficjalny komunikat WordPress dotyczący wersji 7.0.2

Poprawione wersje to:

WordPress 6.8.6,
WordPress 6.9.5,
WordPress 7.0.2.

Bezpieczna jest również każda nowsza wersja zawierająca te poprawki.

Czym jest wp2shell?

Nazwa wp2shell opisuje łańcuch wykorzystujący dwie podatności w WordPress Core:

CVE-2026-60137 — podatność SQL injection związana z obsługą parametru author__not_in przez mechanizm WP_Query,
CVE-2026-63030 — błąd w obsłudze tras przez funkcję grupowego wykonywania żądań WordPress REST API.

Druga luka umożliwia ominięcie ograniczeń, które normalnie chronią dostęp do funkcji wymagających uwierzytelnienia. Po połączeniu obu błędów atakujący może uzyskać możliwość wykonania kodu bez wcześniejszego logowania.

Nazwa „wp2shell” nawiązuje do możliwości umieszczenia na serwerze webshella, czyli złośliwego skryptu pozwalającego napastnikowi zdalnie sterować stroną i wykonywać polecenia.

Które wersje WordPressa są podatne?

Pełny łańcuch umożliwiający zdalne wykonanie kodu dotyczy:

WordPressa 6.9.0–6.9.4,
WordPressa 7.0.0–7.0.1.

Wersje WordPressa 6.8.0–6.8.5 są podatne na CVE-2026-60137, ale nie na cały opisany łańcuch zdalnego wykonania kodu. Mimo to również wymagają pilnej aktualizacji do wersji 6.8.6 lub nowszej.

Dokładne zestawienie podatnych i poprawionych wersji opublikował VulnCheck w analizie wp2shell.

Linia WordPressa	Podatne wersje	Wersja z poprawką
6.8	6.8.0–6.8.5	6.8.6
6.9	6.9.0–6.9.4	6.9.5
7.0	7.0.0–7.0.1	7.0.2

Dlaczego wp2shell jest szczególnie niebezpieczny?

Większość nagłaśnianych luk w WordPressie dotyczy określonej wtyczki albo motywu. Wtedy zagrożone są tylko strony, na których zainstalowano konkretny komponent.

Wp2shell znajduje się w samym rdzeniu WordPressa. Oznacza to, że zagrożona może być standardowa instalacja bez dodatkowych wtyczek.

Atak:

nie wymaga konta użytkownika,
nie wymaga hasła administratora,
nie wymaga kliknięcia przez właściciela strony,
może zostać przeprowadzony zdalnie,
może prowadzić do utworzenia nowego administratora,
może zakończyć się instalacją webshella lub złośliwej wtyczki.

Z punktu widzenia właściciela małej strony serwer może zostać zaatakowany automatycznie przez skaner wyszukujący podatne wersje. Firma nie musi być indywidualnie wybranym celem.

Ataki rozpoczęły się krótko po publikacji poprawek

Kilka zespołów bezpieczeństwa potwierdziło wykorzystanie wp2shell przeciwko rzeczywistym systemom.

VulnCheck zaobserwował próby ataków skierowane na produkcyjne instalacje WordPressa. Badacze ustalili również, że napastnik może wykorzystać błędną obsługę żądań do utworzenia złośliwego konta administracyjnego, bez konieczności wcześniejszego łamania przechwyconego hasła.

Wiz Research wykrył ataki prowadzące do instalowania trwałych webshelli na podatnych serwerach. Analiza rzeczywistych ataków przygotowana przez Wiz

Oznacza to, że problem nie jest już wyłącznie teoretyczny. Samo opublikowanie poprawki nie chroni strony, dopóki aktualizacja nie zostanie rzeczywiście zainstalowana.

Co może zrobić napastnik po przejęciu WordPressa?

Skutki zależą od konfiguracji serwera i uprawnień procesu obsługującego stronę. Potencjalne działania obejmują:

zmianę treści witryny,
utworzenie nowego administratora,
instalację złośliwej wtyczki,
umieszczenie webshella,
przekierowanie odwiedzających na strony phishingowe,
kradzież bazy danych,
pobranie skrótów haseł użytkowników,
dostęp do danych klientów i formularzy,
zmianę plików motywu,
wysyłanie spamu z serwera,
wykorzystanie domeny do dystrybucji malware,
przejęcie konfiguracji poczty lub kluczy API,
atakowanie innych usług znajdujących się na tym samym hostingu.

Jeżeli w pliku wp-config.php znajdują się dane dostępowe do bazy, klucze integracji lub inne sekrety, należy uwzględnić możliwość ich ujawnienia.

Jak sprawdzić wersję WordPressa?

Metoda 1: panel administracyjny

Po zalogowaniu przejdź do:

Kokpit → Aktualizacje

Na ekranie powinna znajdować się informacja o obecnej wersji oraz dostępnych aktualizacjach.

Wersję można również zobaczyć na dole niektórych ekranów panelu administracyjnego.

Metoda 2: panel hostingu

Jeżeli strona jest zarządzana przez instalator znajdujący się w panelu hostingowym, wersja WordPressa może być widoczna na liście instalacji CMS.

Należy jednak potwierdzić wersję również w samym WordPressie. Dane w panelu hostingu nie zawsze są odświeżane natychmiast.

Metoda 3: WP-CLI

Administrator posiadający dostęp do serwera może wykonać:

wp core version

Polecenie powinno zostać uruchomione w katalogu konkretnej instalacji WordPressa i na koncie posiadającym odpowiednie uprawnienia.

Jak bezpiecznie wykonać aktualizację?

1. Zabezpiecz aktualną kopię

Przed zmianą zachowaj:

bazę danych,
katalog wp-content,
plik wp-config.php,
konfigurację serwera lub hostingu,
informacje o aktualnie używanym motywie i wtyczkach.

Kopia nie powinna zastępować wcześniejszych backupów. Jeżeli strona została już zaatakowana, najnowsza kopia również może zawierać webshell albo złośliwego użytkownika.

2. Zainstaluj poprawioną wersję

W panelu WordPressa wybierz:

Kokpit → Aktualizacje → Zaktualizuj teraz

Minimalne wymagane wersje to 6.8.6, 6.9.5 lub 7.0.2 — zależnie od używanej linii WordPressa.

Jeśli aktualizacja nie działa, należy skontaktować się z administratorem hostingu. Nie powinno się odkładać poprawki wyłącznie ze względu na obawę przed problemem ze zgodnością wtyczki.

3. Zweryfikuj wynik

Po aktualizacji:

ponownie sprawdź numer wersji,
otwórz stronę główną i najważniejsze podstrony,
przetestuj formularz kontaktowy,
sprawdź panel administratora,
zweryfikuj, czy nie pojawiły się błędy PHP,
upewnij się, że aktualizacja zakończyła się bez komunikatu o niepowodzeniu.

Administrator korzystający z WP-CLI może dodatkowo sprawdzić integralność rdzenia:

wp core verify-checksums

Niezgodności wymagają wyjaśnienia, ale nie każda zmiana musi oznaczać włamanie. Niektórzy dostawcy hostingu modyfikują wybrane pliki albo dodają własne elementy.

Aktualizacja nie usuwa skutków wcześniejszego włamania

Jeżeli strona była dostępna z internetu w podatnej wersji, należy uwzględnić możliwość ataku przed instalacją poprawki.

Aktualizacja zamyka lukę, lecz nie usuwa automatycznie:

utworzonego konta administratora,
złośliwej wtyczki,
pliku PHP w katalogu przesyłanych materiałów,
zmienionego motywu,
webshella,
dodatkowego zadania cron,
skradzionego hasła,
przejętego tokenu lub klucza API.

Dlatego po aktualizacji potrzebna jest przynajmniej podstawowa kontrola bezpieczeństwa.

Jak sprawdzić stronę pod kątem kompromitacji?

Skontroluj konta administratorów

Przejdź do:

Użytkownicy → Wszyscy użytkownicy

Sprawdź:

nieznane konta,
nowych administratorów,
zmienione adresy e-mail,
użytkowników utworzonych w ostatnich dniach,
konta o nazwach przypominających usługę systemową.

Nie usuwaj podejrzanego konta przed zapisaniem jego nazwy, adresu e-mail, identyfikatora i daty utworzenia. Informacje mogą być potrzebne podczas analizy.

Sprawdź wtyczki i motywy

Zwróć uwagę na:

nieznane wtyczki,
komponenty z przypadkowymi nazwami,
ostatnio aktywowane dodatki,
wtyczki niewidoczne wcześniej w panelu,
zmodyfikowane pliki aktywnego motywu,
katalog mu-plugins.

Wtyczki typu must-use znajdujące się w wp-content/mu-plugins mogą uruchamiać się automatycznie i nie zawsze wyglądają w panelu tak samo jak zwykłe rozszerzenia.

Przeszukaj katalog przesyłanych plików

Standardowy katalog wp-content/uploads powinien zawierać głównie grafiki, dokumenty i multimedia.

Pliki .php, .phtml, .phar albo pliki o podwójnych rozszerzeniach znajdujące się w tym miejscu wymagają sprawdzenia.

Nie należy jednak usuwać ich automatycznie bez kopii i analizy — niektóre legalne rozwiązania mogą tworzyć nietypowe pliki.

Sprawdź logi serwera

W logach dostępu warto wyszukać nietypowe żądania związane z:

/wp-json/batch/v1,
?rest_route=/batch/v1,
nagłym wywoływaniem wielu tras REST API,
przesyłaniem plików PHP,
logowaniem nowego administratora,
instalacją wtyczki bez wcześniejszej aktywności właściciela.

Samo żądanie do endpointu nie dowodzi skutecznego włamania. Może pochodzić ze skanera bezpieczeństwa albo nieudanej próby. Znaczenie ma odpowiedź serwera i dalsza aktywność z tego samego adresu.

Zweryfikuj integralność plików

Najbezpieczniej porównać pliki rdzenia z oficjalnym pakietem tej samej wersji. Szczególnie sprawdź:

wp-config.php,
.htaccess,
index.php,
pliki motywu,
pliki w głównym katalogu WordPressa,
zawartość wp-admin i wp-includes,
katalogi wtyczek.

Należy uważać na pliki, które:

powstały niedawno,
mają nazwy podobne do plików systemowych,
zawierają długie zakodowane ciągi,
używają funkcji wykonujących polecenia,
zwracają pozorny błąd 404, ale wykonują kod po podaniu specjalnego parametru.

Co zrobić po wykryciu śladów włamania?

Włącz tryb serwisowy albo ogranicz dostęp do strony.
Nie usuwaj od razu wszystkich podejrzanych plików.
Zabezpiecz kopię witryny, bazy danych i logów.
Zapisz czasy modyfikacji plików oraz dane nieznanych kont.
Zmień hasła do hostingu, WordPressa, bazy danych, SFTP i SSH.
Unieważnij sesje użytkowników i wymień klucze bezpieczeństwa WordPressa.
Zmień ujawnione klucze API oraz dane używane przez formularze i pocztę.
Usuń nieznane konta, webshell i złośliwe wtyczki po zabezpieczeniu dowodów.
Zainstaluj czysty rdzeń WordPressa z oficjalnego źródła.
Ponownie zainstaluj potrzebne wtyczki i motywy z zaufanych pakietów.
Sprawdź inne strony działające na tym samym koncie hostingowym.
Monitoruj logi po ponownym uruchomieniu witryny.

Przy poważnym naruszeniu bezpieczniejsze jest odtworzenie serwisu z czystego środowiska niż ręczne poprawianie pojedynczych plików.

Jeżeli strona przetwarza dane osobowe, trzeba również ocenić, czy doszło do naruszenia ochrony danych wymagającego działań zgodnych z RODO.

Jak ograniczyć podobne ryzyko w przyszłości?

Włącz aktualizacje bezpieczeństwa

Drobne aktualizacje WordPressa powinny instalować się automatycznie. Należy jednak monitorować, czy proces faktycznie zakończył się powodzeniem.

Używaj MFA dla administratorów

Uwierzytelnianie wieloskładnikowe nie zatrzyma wp2shell, ponieważ atak nie wymaga logowania. Może jednak ograniczyć dalsze wykorzystanie skradzionych haseł.

Ogranicz liczbę administratorów

Konto używane do codziennego publikowania treści nie zawsze musi posiadać pełne uprawnienia administratora.

Wdróż WAF

Zapora aplikacyjna może ograniczyć automatyczne próby ataku i zapewnić dodatkowy czas na aktualizację. Nie powinna jednak zastępować poprawki w WordPressie.

Cloudflare opublikował reguły chroniące klientów przed opisywanymi podatnościami. Informacja Cloudflare o ochronie przed lukami WordPressa

Przechowuj logi poza serwerem strony

Napastnik posiadający dostęp do serwera może próbować usunąć lokalne logi. Ich kopia w zewnętrznym systemie ułatwia ustalenie przebiegu incydentu.

Regularnie testuj kopie zapasowe

Backup powinien być:

automatyczny,
przechowywany poza podstawowym hostingiem,
chroniony innymi danymi logowania,
dostępny w kilku wersjach historycznych,
okresowo odtwarzany testowo.

Fakty potwierdzone i obszary niepewności

Potwierdzone:

WordPress opublikował 17 lipca 2026 roku awaryjne wersje 6.8.6, 6.9.5 oraz 7.0.2.
Aktualizacje usuwają CVE-2026-60137 i CVE-2026-63030.
Połączenie obu podatności umożliwia nieuwierzytelnione zdalne wykonanie kodu w podatnych wersjach 6.9 i 7.0.
Atak nie wymaga podatnej wtyczki ani motywu.
WordPress włączył wymuszone automatyczne aktualizacje dla podatnych instalacji.
Niezależne zespoły potwierdziły próby wykorzystywania podatności.
W rzeczywistych atakach obserwowano trwałe webshelle.
Sama instalacja poprawki nie usuwa dostępu utworzonego przed aktualizacją.

Nieustalone publicznie:

pełna liczba przejętych stron,
liczba poszkodowanych firm w Polsce,
kompletna lista wykorzystywanych webshelli,
tożsamość wszystkich grup prowadzących ataki,
pełny zakres danych skradzionych z zaatakowanych serwerów.

Ocena: największe ryzyko dotyczy stron, które nie otrzymały wymuszonej aktualizacji albo zostały skompromitowane pomiędzy publikacją szczegółów a instalacją poprawki. Każdą publicznie dostępną instalację z podatnej linii warto nie tylko zaktualizować, lecz również sprawdzić pod kątem wcześniejszego włamania.

Podsumowanie

Wp2shell jest wyjątkowo poważnym zagrożeniem, ponieważ dotyczy rdzenia WordPressa i nie wymaga konta, hasła ani podatnej wtyczki. Administratorzy powinni natychmiast potwierdzić, że korzystają przynajmniej z wersji 6.8.6, 6.9.5 albo 7.0.2.

Aktualizacja jest pierwszym krokiem. Kolejne to sprawdzenie administratorów, wtyczek, plików PHP, logów oraz integralności rdzenia. Jeżeli znaleziono podejrzane zmiany, stronę należy potraktować jak potencjalnie przejętą i rozpocząć pełną procedurę reagowania na incydent.