Wydane 17 lipca nowe wersje WordPress zawierają poprawki bardzo poważnych podatności w kodzie samego systemu. Połączenie obu błędów może skutkować nieautoryzowanym dostępem do bazy danych (możliwość wykonywania zapytań SQL). Konsekwencje udanego użycia podatności są wtedy ograniczone umiejętnościami atakującego. Dostępny jest gotowy PoC, w którym autor dodał m.in. funkcjonalność tzw. webshell. Skrypt wykorzystuje opisywane podatności w dość wyrafinowany sposób – po otrzymaniu dostępu do bazy zakłada tymczasowego użytkownika z rolą Administrator, a następnie z użyciem tego konta instaluje wtyczkę dającą atakującemu dostęp do powłoki systemu operacyjnego. Oczywiście dostęp jest ograniczony prawami użytkownika, na którym działa sama aplikacja, natomiast w żaden sposób nie wpływa to na skalę ryzyka skutecznego użycia exploita.
Chodzi o podatności CVE-2026-60137 i CVE-2026-63030. Pierwsza z nich to zwykła podatność SQL injection i jest klasyfikowana jako Moderate, ale druga jest nieco bardziej „ciekawa”, bo dotyczy krytycznego błędu w obsłudze REST API systemu WordPress. Zagrożone wersje to 6.8.0-6.8.5, 6.9.0-6.9.4 i 7.0.0-7.0.1.
Techniczne szczegóły na ten moment nie zostały ujawnione, co zostało uzasadnione powagą błędów, ale też koniecznością ich naprawy przez zespół odpowiedzialny za WordPress – w innym scenariuszu moglibyśmy spodziewać się masowych ataków. Niemniej na GitHub możemy bez większych trudności znaleźć działające exploity, choćby ten podany w pierwszym akapicie. Prawdopodobnie więc w niedużej perspektywie czasu podatności będą dokładnie przedstawione.
Osobom zainteresowanym sugeruję jednak sprawdzić listę commitów przykładowo dla tagu 7.0.2, bo zawierają one zmiany usuwające obie podatności w kodzie PHP.
Zostały wydane aktualizacje, a ich instalacja powinna zostać przeprowadzana automatycznie. Jeśli jednak wyłączyliśmy ten mechanizm – co jest jak najbardziej słuszną praktyką w środowiskach produkcyjnych – to zaleca się jak najszybsze wdrożenie zmian. Dla mniej złożonych serwisów wykonanie automatycznej aktualizacji WordPress najpewniej zakończy się powodzeniem i nikt nie zauważy zmian, natomiast niezaplanowana aktualizacja (przykładowo bez wcześniejszego wykonania kopii zapasowej bazy danych i katalogu) nie jest optymalną sytuacją, bo jak każde oprogramowanie może zawierać zwyczajne błędy. Dodatkowo jeśli modyfikowany był kod „core” WordPress, to wdrożenie aktualizacji o losowej porze może okazać się co najmniej problematyczne dla zespołu programistów.
W przypadku braku możliwości podniesienia wersji przydatne będzie zablokowanie/ograniczenie na poziomie serwera HTTP, load balancera itp. dostępu do /wp-json/batch/v1 oraz rest_route=/batch/v1 (ten endpoint jest stosowany, gdy nie zmieniono struktury adresów w Narzędzia -> Bezpośrednie odnośniki).
W pewnym sensie są to wyjątkowe podatności, bo o ile błędy w WordPress nie należą do rzadkości (wynika to przede wszystkim z popularności tego systemu CMS), to z reguły znajdowane są we wtyczkach czy motywach – więc nie każda instalacja jest podatna. Tym razem podatności obejmują „core” WordPress, co oznacza, że wymienione wersje systemu są zagrożone zaraz po ich publicznym uruchomieniu.
O powadze sytuacji może świadczyć fakt, że firma Cloudflare zdążyła dodać odpowiednie reguły do swojego rozwiązania WAF. Jeśli ruch do naszej instancji WordPress jest obsługiwany przez tę usługę, to prawdopodobieństwo udanego ataku jest niskie. Rzecz jasna wdrożenie aktualizacji WordPress wciąż pozostaje zalecane. Jeśli atakującemu uda się odkryć prawdziwy adres serwera, na którym hostowany jest WordPress (bo dla przykładu nasza subdomena w DNS kieruje bezpośrednio do tego serwera i nie jest obsługiwana przez Cloudflare), to będzie mógł użyć obu podatności poprzedzając ten etap dodaniem wpisu do pliku hosts.
Przeprowadzenie ataku nie wymaga znajomości dostępów czy nawet posiadania konta w systemie. Osoby mniej techniczne mogą nawet nie zauważyć śladów ataku do czasu wykradnięcia danych z ich serwisu czy uszkodzenia aplikacji. Atakujący jest w stanie zapewnić sobie „trwały” dostęp do serwera i wykonywać rekonesans także innych działających aplikacji czy usług zainstalowanych w systemie operacyjnym. Nie można liczyć, że osoby nie zajmujące się zawodowo utrzymaniem IT samodzielnie zweryfikują np. logi serwera.
Administratorzy serwerów powinni zablokować niektóre „wrażliwe” funkcje PHP. Webshell’e opierają swoje działanie na użyciu exec(), shell_exec(), system() czy też passthru(). Jeśli zostaną one zablokowane (disable_functions w pliku php.ini dla PHP-FPM), to w łatwy sposób ograniczymy ryzyko podatności RCE. W naszym przypadku po zablokowaniu shell_exec() nie udało się wykonać exploita – WordPress pozostaje podatny, ale użycie webshell’a zakończyło się błędem.
W error.log została odnotowana przyczyna:
[Sun Jul 19 16:13:46.465259 2026] [proxy_fcgi:error] [pid 17819:tid 129155955926720] [client 192.168.1.110:0] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to undefined function shell_exec() in /home/avlab/web/test.avlab.pl/public_html/wp-content/plugins/wp2shell_13a7dbe4/wp2shell_13a7dbe4.php:8\nStack trace:\n#0 {main}\n thrown in /home/avlab/web/test.avlab.pl/public_html/wp-content/plugins/wp2shell_13a7dbe4/wp2shell_13a7dbe4.php on line 8'
Podatna jest też edycja Bedrock, czyli nieoficjalna wersja WordPress z lepiej dostosowaną do współczesnych standardów strukturą katalogów i obsługą zmiennych z pliku .env. Skrypt co prawda nie jest w stanie przeprowadzić instalacji webshell’a (podejrzewam, że oczekuje zwrócenia kodu 200 z /wp-login.php, gdzie Bedrock przekierowuje z kodem 302 na używaną lokalizację panelu logowania, czyli /wp/wp-login.php), ale jak widać zapytania do bazy danych są wykonywane pomyślnie.
Popularność i powszechny dostęp do kodu źródłowego WordPress sprawiają, że znalezienie luk jest ułatwione. W dobie skanerów AI można zakładać nieco czarne scenariusze i większą ilość znajdowanych błędów. Tym razem osoby odpowiedzialne za wykrycie obu podatności zgłosiły fakt ich istnienia, ale następnym razem odkrycie błędu może być wynikiem pracy osoby o wątpliwej moralności. Natomiast nasze testy z użycia podatności po raz kolejny udowodniły, że minimalizacja dostępu i hardening usług pozostają aktualną oraz skuteczną strategią.
W niektórych przypadkach warto rozważyć zastosowanie innego systemu CMS. Dobrym przykładem będzie Ghost, który sprawdzaliśmy kilka dni temu. WordPress jest odpowiednim wyborem dla prostych serwisów, ale dodawanie nowych funkcjonalności (nie wszystko można osiągnąć kolejnymi wtyczkami) w tym systemie jest utrudnione, stąd użycie alternatywy może okazać się zasadne.
