Patchstack opisał kampanię ataków na krytyczny łańcuch podatności w WordPress core. Najważniejszy konkret: pierwsze realne próby wykorzystania pojawiły się około 90 minut po wydaniu WordPressa 7.0.2, czyli zanim wielu właścicieli stron zdążyło w ogóle zauważyć aktualizację.
To nie jest news z kategorii: kiedyś może będzie groźnie. Według danych Patchstack atakujący bardzo szybko przeszli od analizy poprawki do skanowania i prób przejęcia niezałatanych instalacji.
Kluczowe wnioski
- Pierwsze próby wykorzystania luki pojawiły się około 90 minut po wydaniu WordPressa 7.0.2.
- Problem dotyczy WordPressa 6.8-7.0.1 w zależności od konkretnego CVE.
- Poprawione wersje to WordPress 7.0.2, 6.9.5 i 6.8.6.
- Patchstack zablokował ponad 65 000 prób ataku z ponad 1500 adresów IP.
- Reguły WAF patrzące tylko na URL mogą nie wykrywać wariantu z rest_route=/batch/v1 w ciele POST.
Które wersje WordPressa są zagrożone
Opisany łańcuch łączy dwie podatności. CVE-2026-60137 to ułatwiony SQL injection w WP_Query przez parametr author_exclude / author__not_in i według Patchstack dotyczy WordPressa od 6.8 do 7.0.1. CVE-2026-63030 dotyczy pomylenia trasy i handlera w REST API batch endpoint i obejmuje wersje od 6.9 do 7.0.1.
Oba problemy zostały naprawione w WordPressie 7.0.2, 6.9.5 i 6.8.6. Patchstack zaznacza też, że starsze gałęzie, takie jak 6.1 i 6.2, nie są dotknięte tym konkretnym łańcuchem, bo podatny kod pojawił się później.
Jak wyglądały ataki według telemetryki Patchstack
W dniach po ujawnieniu problemu Patchstack zablokował ponad 65 000 prób wykorzystania tych podatności z ponad 1500 unikalnych adresów IP. Firma podkreśla, że reguły RapidMitigate aktywowały się na stronach z faktycznie podatnymi wersjami, więc mowa o ruchu wymierzonym w niezałatane instalacje.
Około 97% zablokowanych prób celowało w REST batch endpoint, najczęściej przez /?rest_route=/batch/v1 lub /wp-json/batch/v1. Około trzy czwarte żądań niosło próbę SQL injection w parametrze author_exclude, z typowym zestawem sztuczek: różna wielkość liter, komentarze inline, kodowanie URL i opóźnienia typu SLEEP.
Dlaczego to może skończyć się przejęciem strony
Na papierze jeden element łańcucha jest tylko odczytowym SQL injection, a drugi nie daje sam z siebie magicznego konta administratora. Problem zaczyna się, gdy te błędy zostaną połączone. Patchstack opisuje, że publiczny exploit, znany jako wp2shell, może na niechronionych stronach WordPress 6.9-7.0.1 prowadzić do utworzenia nowego konta administratora, a potem do zdalnego wykonania kodu.
W praktyce wygląda to znajomo i niezbyt romantycznie: atakujący zdobywa admina, loguje się, wrzuca wtyczkę będącą webShellem albo inny plik PHP, a potem strona przestaje być tylko stroną firmową. Staje się czyimś narzędziem.
WAF patrzący tylko na adres URL może nie wystarczyć
Ciekawy, ale dla administratorów niewygodny szczegół: Patchstack wykrył, że wiele pierwszych reguł WAF skupiało się na szukaniu batch/v1 w adresie URL. To działało na publiczne proof-of-concept, ale nie pokrywało całej powierzchni problemu.
Według Patchstack WordPress może odczytać rest_route=/batch/v1 z ciała żądania POST przed query stringiem. Czyli żądanie może wyglądać jak zwykły POST na stronę główną, a mimo to trafić do batch endpointu. Od około 17:00 UTC 21 lipca Patchstack zaczął widzieć próby wykorzystujące właśnie takie warianty, a inni hosterzy zgłaszali podobne obejścia.
Co teraz sprawdzić na swojej stronie
Jeśli utrzymujesz WordPressa albo WooCommerce, pierwsza rzecz jest nudna, ale konieczna: upewnij się, że strona działa na WordPressie 7.0.2, 6.9.5, 6.8.6 albo nowszym odpowiedniku. Przy takich czasach reakcji atakujących odkładanie aktualizacji na spokojny weekend brzmi jak proszenie się o dodatkową pracę.
Po aktualizacji warto sprawdzić ślady kompromitacji: nieznane konta administratorów, niespodziewane wtyczki, podejrzane pliki PHP w katalogu uploads oraz logi dla REST batch endpointu. Szukaj nie tylko /wp-json/batch/v1 i ?rest_route=/batch/v1, ale też wariantów, gdzie rest_route=/batch/v1 pojawia się w ciele POST.
Źródło i dalsze szczegóły
Pełny opis kampanii, przykłady payloadów, zakres wersji i szczegóły dotyczące obejścia reguł WAF są w analizie Patchstack: Ninety minutes: watching attackers weaponize the WordPress core RCE. Jeśli odpowiadasz za bezpieczeństwo większej liczby stron, warto przeczytać cały wpis u źródła, a nie tylko odhaczyć samą aktualizację.
Najczesciej zadawane pytania
Jakie wersje WordPressa zawierają poprawki dla opisanego łańcucha luk?
Według Patchstack oba problemy naprawiono w WordPressie 7.0.2, 6.9.5 i 6.8.6. Strony powinny działać na jednej z tych wersji albo na nowszym odpowiedniku.
Czy starsze instalacje WordPressa, takie jak 6.1 lub 6.2, są objęte tym konkretnym łańcuchem?
Patchstack wskazuje, że starsze gałęzie, takie jak 6.1 i 6.2, nie są dotknięte tym konkretnym łańcuchem, ponieważ podatny kod pojawił się później. Zakres zależy od konkretnego CVE: CVE-2026-60137 obejmuje WordPressa 6.8-7.0.1, a CVE-2026-63030 wersje 6.9-7.0.1.
Po czym w logach można rozpoznać próby wykorzystania tej podatności?
Patchstack opisywał ruch do REST batch endpointu, między innymi przez /?rest_route=/batch/v1 oraz /wp-json/batch/v1. Warto sprawdzać także warianty, w których rest_route=/batch/v1 znajduje się w ciele żądania POST, a nie w samym URL.
Dlaczego sama reguła WAF szukająca batch/v1 w adresie URL może być za słaba?
Według Patchstack WordPress może odczytać rest_route=/batch/v1 z ciała żądania POST przed query stringiem. Taki wariant może ominąć reguły, które analizują tylko adres URL.
Co sprawdzić, jeśli strona działała na podatnej wersji WordPressa?
Po aktualizacji warto sprawdzić nieznane konta administratorów, niespodziewane wtyczki, podejrzane pliki PHP w katalogu uploads oraz logi związane z REST batch endpointem. Patchstack opisywał scenariusz, w którym publiczny exploit może prowadzić do utworzenia konta administratora i zdalnego wykonania kodu na niechronionych stronach WordPress 6.9-7.0.1.