Krytyczne dwie podatności w WordPressie tworząc łańcuch prowadzący do zdalnego wykonania kodu (RCE)

Trudno wyobrazić sobie współczesny internet bez WordPressa. Ten blogowy system zarządzania treścią z czasem stał się potężnym narzędziem, z którego korzystają nawet najwięksi gracze. Różne dane wskazują, że udział WordPressa w rynku od lat oscyluje w okolicach 60%. Tym bardziej nie powinno dziwić, że WP ciągle pozostaje w zainteresowaniu badaczy, zarówno tych działających po dobrej, jak i złej stronie mocy. Adam Kues z działu Assetnote w Searchlight Cyber w ramach programu WordPressa na Hacker One zgłosił dwie podatności stanowiące łańcuch ataku nazwany WP2Shell.

TLDR:

• Adam Kues z działu Assetnote w Searchlight Cyber zgłosił dwie podatności w WordPressie. Pierwsza podatność to zwykłe SQL Injection. Druga dotyczy błędu w obsłudze żądań wsadowych REST API. Obie podatności tworzą łańcuch ataku prowadzący do zdalnego wykonania kodu (RCE).
• Do przeprowadzenia ataku nie jest wymagane uwierzytelnienie ani jakakolwiek interakcja ze strony użytkownika. Dostępny jest już proof of concept (PoC).
• Łatajcie się tak szybko, jak to tylko możliwe, a jeśli nie jest to możliwe, zapoznajcie się z poradami dotyczącymi mitygowania tego problemu bezpieczeństwa w dalszej części tekstu.

Pierwsza zgłoszona podatność została oznaczona identyfikatorem CVE-2026-60137. W ramach programu CNA otrzymała ocenę 5.9 w CVSS 3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). To błąd pozwalający na SQL injection w parametrze author__not_in w WP_Query. Taki rodzaj podatności pozwala na wstrzyknięcie własnych danych wejściowych do zapytania SQL. Podatne wersje to 6.8.0 – 6.8.5, 6.9.0 – 6.9.4 oraz 7.0.0 – 7.0.1. Natomiast załatane wersje to odpowiednio 6.8.6, 6.9.5 i 7.0.2.

Druga podatność otrzymała identyfikator CVE-2026-63030 i ocenę 9.8 w ramach programu CNA w CVSS 3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). To błąd w obsłudze żądań wsadowych REST API (batch-route confusion). Luka umożliwia nieuwierzytelnionemu atakującemu wykonanie kodu za pośrednictwem wsadowego endpointa API REST w środowiskach bez trwałej pamięci podręcznej obiektów. Co istotne, do wykorzystania tej luki nie jest wymagane logowanie ani jakakolwiek inna interakcja ze strony uprawnionego użytkownika. Wykorzystanie obydwu tych podatności może doprowadzić do zdalnego wykonania kodu (RCE).

Feralny błąd prowadzący do RCE został wprowadzony w wersji 6.9, która została wydana 2 grudnia 2025 roku. Badacze z Searchlight Cyber na stronie podatności udostępnili tester pokazujący, czy dana strona jest podatna na atak.

Zalecana jest natychmiastowa aktualizacja. Dla podatnych wersji włączone zostały wymuszone aktualizacje automatyczne. W sytuacji, kiedy pilna aktualizacja jest niemożliwa zaleca się blokadę batch route w WAF-ie. Chodzi o ścieżkę /wp-json/batch/v1 oraz formę ciągu zapytania ?rest_route=/batch/v1. Zablokowanie tylko tej pierwszej ścieżki pozostawiłoby otwartą furtkę poprzez drugi sposób komunikowania się z API.

W celu zmniejszenia ryzyka ataku można także wyłączyć API REST dla anonimowych użytkowników (np. Disable WP REST API). Ponadto badacze na swojej stronie zamieścili wtyczkę odrzucającą anonimowe żądania wsadowe (batch requests). Użytkownicy korzystający z Cloudflare oraz posiadający plany Pro, Business lub Enterprise powinni upewnić się, że Cloudflare Managed Rules są włączone. Klienci korzystający z planów bezpłatnych są automatycznie chronieni przez zestaw reguł bezpłatnych. Nowe reguły wdrażane są wraz z domyślną akcją blokowania w Managed Ruleset.

REST API w WordPressie to interfejs, przez który aplikacje mogą komunikować się ze stroną, wysyłając i odbierając dane w formacie JSON. Dzięki REST API można m.in. pobierać posty, tworzyć treści lub aktualizować wpisy. WordPress podkreśla, że publiczna treść jest zwykle dostępna publicznie przez REST API, a prywatne treści wymagają uwierzytelnienia. W tym przypadku problem dotyczy mechanizmu batch route, który pozwala wysłać wiele żądań REST API w jednym żądaniu HTTP. Warto mieć świadomość, że zastosowanie środków zaradczych w określonych przypadkach może zakłócić poprawne działanie REST API, a tym samym wpłynąć na działanie blokowego edytora i innych funkcji strony.

Niestety, transparentność projektu open source, jakim jest WordPress, umożliwiła szybką analizę wprowadzonych poprawek, na podstawie której powstał już gotowy do użycia eksploit udostępniony w serwisie GitHub. Co prawda w prowadzonym przez CISA rejestrze KEV nie ma jeszcze dostępnych informacji o aktywnym wykorzystaniu podatności, jednak wydaje się to tylko kwestią czasu. Na przykład w przeszłości dzięki błędowi we wtyczce cache’ującej Breeze grupie WP-SHELLSTORM udało się uzyskać nieautoryzowany dostęp do ponad 17 000 instancji WordPressa. W tym przypadku mamy do czynienia z błędem bezpośrednio w samym WordPressie, co może tylko spotęgować skalę skutków spodziewanych ataków.

Jeśli posiadasz stronę korzystającą z WordPressa upewnij się, że nie działa ona na podatnej wersji i w razie potrzeby niezwłocznie ją zaktualizuj. Jeżeli nie możesz zaktualizować, zastosuj się do porad w piątym i szóstym akapicie. Aby upewnić się, czy Twoja strona jest podatna na atak możesz skorzystać z testera na stronie podatności. Sprawdź, czy automatyczne aktualizacje zostały włączone. Z pewnością mechanizm ten przyda się jeszcze nie raz. Warto sprawdzić, czy nie ma nieznanych kont administratorów i ostatnio modyfikowanych plików. Warto także przejrzeć logi pod kątem nietypowej aktywności REST API.

~pu