Podatność odkrył i odpowiedzialnie zgłosił Adam Kues z firmy Assetnote, należącej do Searchlight Cyber .

Identyfikatory CVE

wp2shell nie jest pojedynczym błędem, lecz połączeniem dwóch podatności :

• CVE-2026-63030 — problem pomylenia tras w zbiorczym endpoincie REST API. Podatność została sklasyfikowana jako krytyczna, a jej ocena CVSS wynosi 9,8 . W początkowych doniesieniach pojawiała się wartość 7,5, jednak później wielu dostawców zabezpieczeń podawało 9,8 .
• CVE-2026-60137 — nieuwierzytelnione wstrzyknięcie SQL w parametrze author__not_in klasy WP_Query. Błąd oceniono jako poważny .

Które wersje WordPressa były podatne?

Zagrożone były:

• WordPress 6.9.x — wersje od 6.9.0 do 6.9.4,
• WordPress 7.0.x — wersje 7.0.0 i 7.0.1,
• starsza gałąź 6.8.x, dla której przygotowano poprawkę do wersji 6.8.6 .

W praktyce należy zaktualizować system co najmniej do wersji 6.9.5, 7.0.2 albo 6.8.6, zależnie od używanej gałęzi.

Jak działał łańcuch wp2shell?

Pierwszy element ataku, CVE-2026-60137, pozwalał przesłać specjalnie przygotowane żądanie HTTP do parametru author__not_in i wstrzyknąć własne zapytania SQL do bazy WordPressa. Atakujący nie potrzebował do tego konta ani danych logowania.

Drugi błąd, CVE-2026-63030, dotyczył zbiorczego endpointu REST API dostępnego pod adresem /wp-json/batch/v1. Endpoint ten obsługuje wiele podrzędnych żądań w ramach jednego wywołania. Błąd w analizowaniu żądań powodował rozjechanie się dwóch wewnętrznych tablic, co mogło pozwolić na ominięcie ograniczeń tras i wywołanie wewnętrznych operacji API, które normalnie nie powinny być dostępne .

Po połączeniu obu błędów napastnik mógł wykorzystać endpoint zbiorczy do wywołania wstrzyknięcia SQL, a następnie uzyskać pełne zdalne wykonanie kodu. Możliwe ścieżki obejmowały między innymi:

• zapisanie dowolnych danych, np. PHP-owego webshella, w systemie plików za pomocą polecenia MySQL INTO OUTFILE,
• modyfikację opcji WordPressa, które prowadzą do wykonania kodu PHP .

Atak nie wymagał uwierzytelnienia, zainstalowanych wtyczek ani nietypowej konfiguracji — wystarczała standardowa instalacja WordPressa . 18 lipca opublikowano publiczny tester podatności pod adresem wp2shell.com, a w obiegu znalazł się także działający kod PoC .

Warto zaznaczyć, że używanie trwałego cache obiektowego, takiego jak Redis lub Memcached, może częściowo zmienić albo utrudnić ścieżkę ataku. Nie usuwa jednak samej podatności .

Co zrobić, aby zabezpieczyć stronę?

1. Zaktualizuj WordPressa natychmiast. Wybierz wersję 6.9.5, 7.0.2 lub 6.8.6, odpowiednią dla używanej gałęzi. Witryny z włączonymi aktualizacjami automatycznymi w wielu przypadkach powinny otrzymać poprawkę wymuszoną przez WordPress.org .
2. Potwierdź zainstalowaną wersję. W panelu administracyjnym przejdź do Kokpit → Aktualizacje albo sprawdź wartość w pliku wp-includes/version.php.
3. Jeśli aktualizacja jest chwilowo niemożliwa, zastosuj tymczasową ochronę. Może nią być wirtualna poprawka lub reguła zapory WAF. Cloudflare wdrożył reguły blokujące wektory ataku związane z wp2shell .
4. Sprawdź oznaki naruszenia bezpieczeństwa. Zwróć uwagę na nieoczekiwane pliki w katalogu wp-content/uploads/, nieznane konta administratorów i nietypowe wpisy w bazie danych. Nie potwierdzono masowej eksploatacji, ale publiczny PoC oznacza, że skanowanie podatnych stron mogło już się rozpocząć.
5. Ogranicz uprawnienia użytkownika bazy danych. Sprawdź, czy konto używane przez WordPressa nie ma uprawnienia FILE, które umożliwia wykorzystanie INTO OUTFILE. Może to ograniczyć jedną ze ścieżek prowadzących do RCE.

Dlaczego otwarty kod WordPressa zwiększa ryzyko?

Brak potwierdzonej masowej eksploatacji nie oznacza, że można czekać z aktualizacją. W przypadku oprogramowania open source opublikowana poprawka może bardzo szybko ujawnić, gdzie znajdował się błąd.

• Łatwe porównanie kodu. Każdy może pobrać poprawioną wersję WordPressa, porównać ją z wersją podatną i odtworzyć ścieżkę ataku w ciągu kilku godzin od publikacji poprawki. Firmy z branży bezpieczeństwa potwierdzały, że porównanie kodu szybko wskazuje zmienione, podatne fragmenty .
• Krótszy czas na reakcję administratorów. W przypadku zamkniętego oprogramowania opracowanie exploita często wymaga niezależnych badań. W projekcie open source sama poprawka może dostarczyć napastnikom szczegółowych wskazówek. Obrońcy muszą więc działać w ciągu godzin, a nie dni.
• Ogromna i zróżnicowana baza instalacji. WordPress obsługuje około 43% wszystkich stron internetowych. Miliony witryn są zarządzane z różną dbałością o bezpieczeństwo; część z nich pozostaje nieaktualna, korzysta ze starych wersji PHP lub nie ma włączonych aktualizacji automatycznych .
• Niski próg wykorzystania. Tester PoC i kod exploita zostały opublikowane w ciągu 24 godzin od wydania poprawki . To ułatwia przekształcenie ich w narzędzie do masowego skanowania.
• Brak bariery uwierzytelnienia. Atak działał przed logowaniem i na standardowej instalacji. Napastnik nie potrzebował prawidłowych danych dostępowych, podatnej wtyczki ani specjalnych ustawień .

Najważniejszy wniosek jest prosty: w przypadku wp2shell sama poprawka zaczęła pełnić funkcję szczegółowego opisu podatności. W połączeniu z ogromną liczbą instalacji WordPressa tworzy to długi ogon potencjalnie niezałatanych celów — nawet jeśli nie odnotowano jeszcze oficjalnie potwierdzonej eksploatacji na dużą skalę.

Podatność odkrył i odpowiedzialnie zgłosił Adam Kues z firmy Assetnote, należącej do Searchlight Cyber .

Identyfikatory CVE

wp2shell nie jest pojedynczym błędem, lecz połączeniem dwóch podatności :

• CVE-2026-63030 — problem pomylenia tras w zbiorczym endpoincie REST API. Podatność została sklasyfikowana jako krytyczna, a jej ocena CVSS wynosi 9,8 . W początkowych doniesieniach pojawiała się wartość 7,5, jednak później wielu dostawców zabezpieczeń podawało 9,8 .
• CVE-2026-60137 — nieuwierzytelnione wstrzyknięcie SQL w parametrze author__not_in klasy WP_Query. Błąd oceniono jako poważny .

Które wersje WordPressa były podatne?

Zagrożone były:

• WordPress 6.9.x — wersje od 6.9.0 do 6.9.4,
• WordPress 7.0.x — wersje 7.0.0 i 7.0.1,
• starsza gałąź 6.8.x, dla której przygotowano poprawkę do wersji 6.8.6 .

W praktyce należy zaktualizować system co najmniej do wersji 6.9.5, 7.0.2 albo 6.8.6, zależnie od używanej gałęzi.

Jak działał łańcuch wp2shell?

Pierwszy element ataku, CVE-2026-60137, pozwalał przesłać specjalnie przygotowane żądanie HTTP do parametru author__not_in i wstrzyknąć własne zapytania SQL do bazy WordPressa. Atakujący nie potrzebował do tego konta ani danych logowania.

Drugi błąd, CVE-2026-63030, dotyczył zbiorczego endpointu REST API dostępnego pod adresem /wp-json/batch/v1. Endpoint ten obsługuje wiele podrzędnych żądań w ramach jednego wywołania. Błąd w analizowaniu żądań powodował rozjechanie się dwóch wewnętrznych tablic, co mogło pozwolić na ominięcie ograniczeń tras i wywołanie wewnętrznych operacji API, które normalnie nie powinny być dostępne .

Po połączeniu obu błędów napastnik mógł wykorzystać endpoint zbiorczy do wywołania wstrzyknięcia SQL, a następnie uzyskać pełne zdalne wykonanie kodu. Możliwe ścieżki obejmowały między innymi:

• zapisanie dowolnych danych, np. PHP-owego webshella, w systemie plików za pomocą polecenia MySQL INTO OUTFILE,
• modyfikację opcji WordPressa, które prowadzą do wykonania kodu PHP .

Atak nie wymagał uwierzytelnienia, zainstalowanych wtyczek ani nietypowej konfiguracji — wystarczała standardowa instalacja WordPressa . 18 lipca opublikowano publiczny tester podatności pod adresem wp2shell.com, a w obiegu znalazł się także działający kod PoC .

Warto zaznaczyć, że używanie trwałego cache obiektowego, takiego jak Redis lub Memcached, może częściowo zmienić albo utrudnić ścieżkę ataku. Nie usuwa jednak samej podatności .

Co zrobić, aby zabezpieczyć stronę?

1. Zaktualizuj WordPressa natychmiast. Wybierz wersję 6.9.5, 7.0.2 lub 6.8.6, odpowiednią dla używanej gałęzi. Witryny z włączonymi aktualizacjami automatycznymi w wielu przypadkach powinny otrzymać poprawkę wymuszoną przez WordPress.org .
2. Potwierdź zainstalowaną wersję. W panelu administracyjnym przejdź do Kokpit → Aktualizacje albo sprawdź wartość w pliku wp-includes/version.php.
3. Jeśli aktualizacja jest chwilowo niemożliwa, zastosuj tymczasową ochronę. Może nią być wirtualna poprawka lub reguła zapory WAF. Cloudflare wdrożył reguły blokujące wektory ataku związane z wp2shell .
4. Sprawdź oznaki naruszenia bezpieczeństwa. Zwróć uwagę na nieoczekiwane pliki w katalogu wp-content/uploads/, nieznane konta administratorów i nietypowe wpisy w bazie danych. Nie potwierdzono masowej eksploatacji, ale publiczny PoC oznacza, że skanowanie podatnych stron mogło już się rozpocząć.
5. Ogranicz uprawnienia użytkownika bazy danych. Sprawdź, czy konto używane przez WordPressa nie ma uprawnienia FILE, które umożliwia wykorzystanie INTO OUTFILE. Może to ograniczyć jedną ze ścieżek prowadzących do RCE.

Dlaczego otwarty kod WordPressa zwiększa ryzyko?

Brak potwierdzonej masowej eksploatacji nie oznacza, że można czekać z aktualizacją. W przypadku oprogramowania open source opublikowana poprawka może bardzo szybko ujawnić, gdzie znajdował się błąd.

• Łatwe porównanie kodu. Każdy może pobrać poprawioną wersję WordPressa, porównać ją z wersją podatną i odtworzyć ścieżkę ataku w ciągu kilku godzin od publikacji poprawki. Firmy z branży bezpieczeństwa potwierdzały, że porównanie kodu szybko wskazuje zmienione, podatne fragmenty .
• Krótszy czas na reakcję administratorów. W przypadku zamkniętego oprogramowania opracowanie exploita często wymaga niezależnych badań. W projekcie open source sama poprawka może dostarczyć napastnikom szczegółowych wskazówek. Obrońcy muszą więc działać w ciągu godzin, a nie dni.
• Ogromna i zróżnicowana baza instalacji. WordPress obsługuje około 43% wszystkich stron internetowych. Miliony witryn są zarządzane z różną dbałością o bezpieczeństwo; część z nich pozostaje nieaktualna, korzysta ze starych wersji PHP lub nie ma włączonych aktualizacji automatycznych .
• Niski próg wykorzystania. Tester PoC i kod exploita zostały opublikowane w ciągu 24 godzin od wydania poprawki . To ułatwia przekształcenie ich w narzędzie do masowego skanowania.
• Brak bariery uwierzytelnienia. Atak działał przed logowaniem i na standardowej instalacji. Napastnik nie potrzebował prawidłowych danych dostępowych, podatnej wtyczki ani specjalnych ustawień .

Najważniejszy wniosek jest prosty: w przypadku wp2shell sama poprawka zaczęła pełnić funkcję szczegółowego opisu podatności. W połączeniu z ogromną liczbą instalacji WordPressa tworzy to długi ogon potencjalnie niezałatanych celów — nawet jeśli nie odnotowano jeszcze oficjalnie potwierdzonej eksploatacji na dużą skalę.