wp2shell: jedno anonimowe żądanie i WordPress przestaje być twój

Co dokładnie znaleziono

Adam Kues z zespołu Assetnote (Searchlight Cyber) zgłosił łańcuch dwóch błędów.

Pierwszy to SQL injection w parametrze author__not_in klasy WP_Query, oznaczony jako CVE-2026-60137. Zgłosili go niezależnie TF1T, dtro i haongo. Sam w sobie pozwala wyciągać z bazy rzeczy, których wyciągać nie powinien.

Drugi dotyczy zbiorczego endpointu REST API pod adresem /wp-json/batch/v1. To pomieszanie tras, oznaczone jako CVE-2026-63030 i sklasyfikowane jako CWE-436, czyli konflikt interpretacji. CVSS 9.8.

Razem dają nieuwierzytelnione wykonanie kodu. Searchlight celowo nie publikuje szczegółów technicznych, żeby dać obrońcom czas. Udostępnił za to stronę, na której sprawdzisz swoją instancję, oraz gotową wtyczkę odrzucającą anonimowe żądania do endpointu batch.

Cloudflare dorzuca szczegół wart uwagi: podatna ścieżka jest osiągalna wtedy, gdy instancja nie korzysta z trwałego cache obiektów. Czyli w większości małych i średnich serwisów, bo Redis czy Memcached to na tym poziomie rzadkość.

Kogo to dotyczy

• Wersje 6.9.0 do 6.9.4: podatne na oba błędy. Łatka jest w 6.9.5.
• Wersje 7.0.0 i 7.0.1: podatne na oba błędy. Łatka jest w 7.0.2.
• Gałąź 6.8: podatna wyłącznie na SQL injection. Łatka jest w 6.8.6.
• Wersje starsze niż 6.8: nie dotyczy.
• Beta 7.1: poprawka weszła w 7.1 beta2.

WordPress uznał sprawę za na tyle poważną, że włączył wymuszone aktualizacje automatyczne dla podatnych wersji. To dobra decyzja i zaraz wyjaśnię, dlaczego mimo wszystko nie zamyka tematu.

Co to znaczy dla firmy

Wykonanie kodu na serwerze WWW to coś więcej niż podmieniona strona główna. Atakujący dostaje proces PHP, a wraz z nim plik wp-config.php z pełnymi poświadczeniami do bazy. W bazie siedzą zwykle zgłoszenia z formularzy kontaktowych, adresy e-mail, czasem CV z zakładki „kariera”, czasem dane zamówień, jeśli w grę wchodzi WooCommerce.

W praktyce oznacza to naruszenie ochrony danych osobowych, 72 godziny na zgłoszenie do UODO i rozmowę z zarządem o tym, dlaczego serwis marketingowy trzymał dane rekrutacyjne.

Do tego dochodzi hosting współdzielony. Rzadko kończy się na jednej przejętej instancji, bo sąsiadów w tym samym katalogu nadrzędnym hostingodawcy izolują gorzej, niż obiecują w ofercie.

Cztery rzeczy, które widzimy przy każdej takiej łatce

Problem rzadko leży w samej aktualizacji. Leży w tym, czego nikt nie policzył.

Nikt nie wie, ile ma WordPressów. Serwis główny jest w inwentarzu zawsze. Ale przy inwentaryzacji powierzchni ataku regularnie wypada strona kampanii sprzed dwóch lat na osobnej subdomenie, kopia testowa pod adresem, który agencja zapomniała wyłączyć, i blog przeniesiony kiedyś „tymczasowo” na inny hosting. Te instancje nie mają właściciela ani monitoringu i to one zostaną z wersją 6.9.3 przez najbliższy kwartał.

Wymuszona aktualizacja to nie to samo co potwierdzona. Aktualizacja WordPress Core potrafi po cichu nie wejść: uprawnienia do plików po migracji, kontener z systemem plików tylko do odczytu, wpis WP_AUTO_UPDATE_CORE ustawiony na false przez programistę trzy lata temu, bo raz coś się rozsypało. Nikt tego potem nie odkręcił. Zajrzyj do panelu i sprawdź numer wersji.

Blokada połowiczna to brak blokady. Endpoint odpowiada w dwóch formach: /wp-json/batch/v1 oraz ?rest_route=/batch/v1. Ta druga działa nawet tam, gdzie wyłączone są bezpośrednie odnośniki. Reguła blokuje pierwszą ścieżkę, ktoś odhacza zadanie, druga zostaje otwarta. Widzieliśmy dokładnie ten schemat przy wcześniejszych łatkach REST API i zakładam, że tym razem będzie podobnie.

Cisza jest tylko chwilowa. Do 18 lipca nikt nie opublikował działającego kodu ani nie potwierdził prób wykorzystania w sieci. To niewiele znaczy. WordPress ma otwarte źródło, a paczki 7.0.1 i 7.0.2 leżą obok siebie w publicznym archiwum. Porównanie dwóch wersji to standardowa droga od cichej łatki do działającego exploita, a masowe atakowanie WordPressa to od lat regularny biznes.

Co zrobić dzisiaj

• Zaktualizuj core do 7.0.2, 6.9.5 albo 6.8.6, zależnie od gałęzi. Potem wejdź w panel i zobacz, jaka wersja faktycznie tam jest.
• Zrób listę wszystkich instancji WordPressa w firmie, łącznie z tymi, których nie utrzymujesz sam. Certyfikaty TLS i rekordy DNS to najszybszy sposób, żeby przypomnieć sobie o zapomnianych subdomenach.
• Jeśli aktualizacja dziś nie wchodzi w grę, zablokuj anonimowy dostęp do obu form endpointu albo wgraj wtyczkę odrzucającą takie żądania w rest_pre_dispatch. To rozwiązanie tymczasowe i potrafi popsuć działające integracje.
• Zabezpiecz logi serwera WWW, WAF i hostingu, zanim zrobisz cokolwiek innego. Jeśli okaże się, że ktoś zdążył, będą jedynym materiałem dowodowym.
• Przejrzyj konta administratorów, pliki zmodyfikowane od dnia wgrania podatnej wersji, zaplanowane zadania WP Cron i wtyczki, których nikt świadomie nie instalował.

Nie szukaj gotowych wskaźników kompromitacji z nazwami plików czy adresami IP. Publiczne komunikaty ich nie podają, więc wszystko, co krąży pod tym hasłem, jest zgadywanką.

Jeden wniosek na dłużej

REST API WordPressa przez lata traktowano jak wewnętrzny interfejs edytora bloków. Jest włączone domyślnie, odpowiada anonimowo i rośnie z każdą wersją core. Za każdym razem, gdy w projekcie pytamy, czy ktoś sprawdzał, co da się wywołać na /wp-json bez logowania, odpowiedź brzmi „to przecież tylko API”.

Ile instancji WordPressa ma twoja firma? Zadaj to pytanie na najbliższym spotkaniu zespołu i policz, ile razy padnie „chyba” albo „to trzeba by sprawdzić u agencji”. Liczba tych „chyba” pokazuje twoją realną powierzchnię ataku.