wp2shell: krytyczna dziura w WordPressie, przed którą ostrzega polskie Ministerstwo Cyfryzacji

By Bogdan Zieliński — ekspert cyberbezpieczeństwa

W świecie bezpieczeństwa aplikacji internetowych rzadko zdarza się moment, w którym cały ekosystem wstrzymuje oddech, a rządowe zespoły reagowania na incydenty wydają pilne rekomendacje. Właśnie taki moment nadszedł w lipcu i sierpniu 2026 roku za sprawą luki, którą społeczność szybko ochrzciła mianem wp2shell. To nie jest kolejna teoretyczna podatność z długiej listy CVE — to w pełni wykorzystywalna, nieuwierzytelniona podatność zdalnego wykonania kodu (RCE), która nie wymaga logowania ani ani jednej wtyczki. Atakujący może przejąć kontrolę nad zwykłą, domyślną instalacją WordPressa w kilka sekund.

Jako osoba, która od lat zajmuje się testami penetracyjnymi i ochroną infrastruktury krytycznej, muszę powiedzieć wprost: jeśli prowadzisz jakąkolwiek stronę na WordPressie, ten artykuł powinieneś przeczytać do końca. Waga zagrożenia jest tak duża, że nawet Pełnomocnik Rządu do spraw Cyberbezpieczeństwa wydał oficjalną rekomendację — o czym w Polsce mówiło się zbyt mało.

Czym dokładnie jest wp2shell?

Nazwa nie jest przypadkowa. „WP” to WordPress, a „shell” to powłoka systemowa — czyli narzędzie, dzięki któremu atakujący może wykonywać dowolne polecenia na serwerze ofiary. wp2shell to łańcuch dwóch podatności w samym jądrze WordPressa, które po połączeniu dają napastnikowi pełną kontrolę nad serwerem bez jakiegokolwiek uwierzytelnienia.

Mechanizm wygląda następująco. Pierwsza podatność, oznaczona jako CVE-2026-63030, dotyczy usługi REST API — a konkretnie problemu nazywanego „batch route confusion”. WordPress pozwala grupować wiele żądań do API w jednym zapytaniu wsadowym przez punkt końcowy `/wp-json/batch/v1`. Błąd w obsłudze tego mechanizmu pozwala atakującemu „pomylić” ścieżki tak, by wywołać operacje, które normalnie w ogóle nie powinny być dostępne dla nieznajomego użytkownika.

Druga część łańcucha to podatność CVE-2026-60137 — wstrzyknięcie SQL (SQL Injection) w zapytaniu `WPQuery authornotin`. To klasyczna i uznawana za „rozwiązaną” klasa błędów, a jednak wciąż potrafi powrócić w rdzeniu najpopularniejszego CMS-a świata. Dzięki niej napastnik może wykonać dowolne zapytania do bazy danych WordPressa.

Kluczowe jest to, co dzieje się po złożeniu obu elementów. Wstrzyknięcie SQL pozwala atakującemu na zapis złośliwego pliku (tzw. web shell) bezpośrednio na serwerze, a następnie jego uruchomienie przez REST API. Efekt końcowy: zdalne wykonanie kodu (RCE) na podatnym na atak systemie — czyli pełne przejęcie kontroli nad stroną, bazą danych i często całym serwerem.

Których wersji dotyczy problem?

To niezwykle istotne pytanie, bo odpowiedź precyzyjnie określa skalę zagrożenia. Zgodnie z analizami zespołów bezpieczeństwa, podatność RCE dotyczy następujących wersji:

WordPress 6.9.0 – 6.9.4 — naprawiona w wersji 6.9.5
WordPress 7.0.0 – 7.0.1 — naprawiona w wersji 7.0.2
WordPress 7.1 beta — naprawiona w wersji 7.1 beta 2

Wersje starsze niż 6.9.0 nie są podatne na RCE, ale uwaga — WordPress 6.8 jest narażony na osobną lukę SQL Injection załatana w tej samej rundzie, dlatego instalacje na 6.8 powinny zostać zaktualizowane do 6.8.6. Wersje sprzed 6.8 nie są dotknięte żadnym z tych problemów.

Co najbardziej niepokoi: luka działa przeciwko czystej, domyślnej instalacji — bez żadnych wtyczek, bez dodatkowych konfiguracji, bez wcześniejszego dostępu. Wystarczy, że strona działa na podatnej wersji, a jej REST API jest dostępne z internetu (a jest domyślnie). Co gorsza, publiczne exploity zostały już opublikowane w sieci, a zespoły bezpieczeństwa potwierdzają aktywną eksploatację w środowisku produkcyjnym („in the wild”). To nie jest hipotetyczne ryzyko — to trwające polowanie.

Rekomendacja Pełnomocnika Rządu do spraw Cyberbezpieczeństwa

W Polsce sprawie poświęcił uwagę najwyższy szczebel odpowiedzialny za cyberbezpieczeństwo państwa. 5 sierpnia 2026 roku Pełnomocnik Rządu do spraw Cyberbezpieczeństwa opublikował oficjalną rekomendację dotyczącą podatności w oprogramowaniu WordPress, wskazując, że skuteczne wykorzystanie luki może prowadzić do przejęcia kontroli nad serwerem, naruszenia poufności, integralności i dostępności danych oraz zakłócenia ciągłości działania usług podmiotów krajowego systemu cyberbezpieczeństwa.

Co istotne, możliwość wystąpienia incydentu krytycznego została potwierdzona w konsultacjach z CSIRT NASK, CSIRT GOV oraz CSIRT MON — czyli z zespołami reagowania, które chronią polską sieć, administrację oraz wojsko. Rekomendacja wprost nakazuje:

niezwłoczną aktualizację wszystkich instancji WordPress do rekomendowanych wersji,
audyt logów systemowych pod kątem podejrzanych zapytań do REST API i parametrów WP_Query,
ograniczenie dostępu do podatnych funkcjonalności REST API, w tym ścieżki `/wp-json/batch/v1` oraz parametru `?rest_route=/batch/v1`,
wdrożenie rozwiązań klasy WAF (Web Application Firewall) w celu blokowania prób ataków.

Jeśli polski rząd na najwyższym szczeblu nakazuje niezwłoczne działanie i konsultuje sprawę z zespołami wojskowymi, to znak, że skala zagrożenia wykracza daleko poza pojedyncze blogi. A kiedy przełożymy to na liczby, obraz robi się naprawdę poważny.

Dziesiątki tysięcy stron w Polsce zagrożonych

Na świecie WordPress zasila ponad 500 milionów witryn — to najpopularniejszy system zarządzania treścią na Ziemi. Polska należy do krajów o szczególnie wysokim nasyceniu WordPressem: szacuje się, że znaczna część polskiego internetu — od małych firm, przez sklepy, po instytucje i media — działa właśnie na tym CMS-ie.

Skutecznie oznacza to, że dziesiątki tysięcy stron w Polsce może być obecnie zagrożonych pełnym przejęciem przez nieuwierzytelnionych atakujących. Wystarczy, że strona nie doczekała się aktualizacji do wersji 7.0.2, 6.9.5 lub 6.8.6. Co gorsza, wielu administratorów wcale nie wie, jakiej wersji WordPressa używa, a jeszcze więcej nie ma żadnych mechanizmów wykrywania naruszeń. Atakujący nie muszą „celować” — mogą masowo przeskanować internet, znaleźć podatne instalacje i przejąć je w automacie, zanim właściciel zdąży cokolwiek zauważyć.

Dlatego traktuję tę sytuację nie jako kolejną decyzję „czy zaktualizować”, ale jako sprawę pilną, wręcz krytyczną. Jeśli masz jakąkolwiek stronę na WordPressie — niezależnie od jej rozmiaru — Twoim pierwszym krokiem powinno być sprawdzenie wersji i natychmiastowa aktualizacja. Drugim krokiem jest audyt: sprawdzenie, czy w logach nie ma podejrzanych zapytań do REST API, czy nikt nie dodał nieznanych użytkowników i czy na serwerze nie pojawiły się obce pliki.

Co powinieneś zrobić teraz?

Pozwól, że podsumuję to konkretnym planem działania, który przekazuję każdemu klientowi w podobnej sytuacji:

Zaktualizuj WordPress natychmiast — do wersji 7.0.2 (jeśli jesteś na 7.x) lub 6.9.5 (na linii 6.9), a w przypadku 6.8 do 6.8.6. WordPress włączył wymuszone automatyczne aktualizacje dla podatnych instalacji, ale nie polegaj na tym — zweryfikuj numer wersji w panelu.
Sprawdź, czy nie zostałeś już zaatakowany — przejrzyj logi pod kątem nietypowych żądań do `/wp-json/batch/v1` i `rest_route=/batch/v1`, sprawdź nieznanych użytkowników administratora oraz świeżo zmodyfikowane pliki na serwerze.
Ogranicz dostęp do REST API — jeśli nie możesz zaktualizować od razu, zablokuj nieuwierzytelniony dostęp do punktu wsadowego API za pomocą WAF lub wtyczki, traktując to jako rozwiązanie tymczasowe, a nie docelowe.
Zadbaj o stałą ochronę — wdroż rozwiązanie klasy WAF, systematyczne kopie zapasowe i regularne monitorowanie.

To wszystko brzmi prosto, ale w praktyce, szczególnie w większych lub starszych instalacjach z setkami wtyczek i niestandardowymi motywami, bezpieczna aktualizacja i weryfikacja braku naruszeń potrafią przysporzyć sporych problemów. Jestem przekonany, że w takich sytuacjach najlepszym rozwiązaniem jest pomoc kompetentnych specjalistów — i tu pozwolę sobie na rekomendację opartą o lata współpracy w branży.

Jeśli nie czujesz się na siłach, by samodzielnie przeprowadzić audyt i naprawę, warto skorzystać z usług firmy specjalizującej się w konsultingu WordPress, jak synteo.com.pl — z zakresie konsultacji dotyczących bezpieczeństwa stron opartych na WordPressie oraz praktycznej pomocy w naprawieniu luk i zabezpieczeniu instalacji. Dobry specjalista nie tylko wgra aktualizację, ale sprawdzi, czy atak już nie miał miejsca, i podpowie, jak zabezpieczyć stronę na przyszłość.

Podsumowanie

wp2shell to jedną z najpoważniejszych podatności WordPressa ostatnich lat: dwie podatności w jądrze składające się w nieuwierzytelnione zdalne wykonanie kodu, działające na domyślnych instalacjach, z opublikowanymi exploitami i potwierdzoną aktywną eksploatacją. Polskie Ministerstwo Cyfryzacji i Pełnomocnik Rządu do spraw Cyberbezpieczeństwa wydali w tej sprawie oficjalną rekomendację — i robili to nie bez powodu. Dziesiątki tysięcy polskich stron są zagrożone.

Nie odkładaj tego na później. Zaktualizuj WordPress, przeprowadź audyt i upewnij się, że Twoja strona nie znalazła się już na celowniku. Bezpieczeństwo w sieci to nie są koszty — to inwestycja, która zaczyna się od jednej aktualizacji. Od Ciebie zależy, czy podejmiesz ją zanim będzie za późno.