Liczba prób dostępu do punktu końcowego batch w REST API WordPressa na naszej infrastrukturze wzrosła ponad trzykrotnie

291 Intercept to nasz cotygodniowy raport o tym, czego automatyczne skanery szukały w naszej własnej infrastrukturze, abyście mogli sprawdzić swoje systemy pod tym samym kątem. Każde wydanie obejmuje tydzień, który zakończył się co najmniej siedem dni wcześniej.

Najwyraźniejszą zmianą w naszej infrastrukturze w tygodniu od 26 października był skok liczby żądań jednego adresu WordPressa: /wp-json/batch/v1. Odpytało go około 40 źródeł, 3.3 razy więcej, niż wynosiła jego średnia tygodniowa z poprzednich trzech tygodni. Od tego punktu końcowego zaczyna się wp2shell, łańcuch dwóch luk w rdzeniu WordPressa, który pozwala atakującemu bez logowania wykonać kod na stronie.

Działo się to w ogólnie bardziej ruchliwym tygodniu: około 620 źródeł sondowało naszą infrastrukturę dostępną z internetu, o 10% więcej niż średnio w poprzednich trzech tygodniach. Głównym celem pozostał WordPress: 66% źródeł atakowało logowanie WordPressa, XML-RPC lub ścieżki wtyczek, co oznacza wzrost o 20%. Skanery częściej pytały też o te części aplikacji, które powinny pozostać prywatne.

Czym jest wp2shell

/wp-json/ to katalog główny REST API WordPressa, a /wp-json/batch/v1 to jego procesor wsadowy, który obsługuje pakiet żądań API naraz. Według Rapid7 wp2shell łączy dwie luki. CVE-2026-63030 to błąd logiczny w tym procesorze wsadowym, a CVE-2026-60137 to podatność typu SQL injection w punkcie końcowym wpisów. Połączone w łańcuch pozwalają osobie bez konta wykonać kod w WordPressie w wersjach od 6.9.0 do 6.9.4 oraz od 7.0.0 do 7.0.1.

Lukę ujawniono 17 lipca 2026 r., a według Rapid7 CISA dodała ją do katalogu Known Exploited Vulnerabilities 21 lipca. Poprawione wydania to 6.9.5, 7.0.2 i 7.1 Beta 2.

Po co szukać luki, do której jest już poprawka? Skanery nie potrzebują, by podatna była każda strona, wystarczy im część z nich. Żądanie praktycznie nic ich nie kosztuje, a każda strona wciąż działająca na podatnej wersji jest warta ponownej wizyty.

Znajoma strona skanowania WordPressa

Skoordynowany zestaw narzędzi obejmujący około 20 źródeł z kilku krajów przechodził tę samą listę około dziesięciu ścieżek. Żądał tego samego pliku pod wieloma nazwami katalogów, takimi jak /wp/wp-includes/wlwmanifest.xml, /shop/wp-includes/wlwmanifest.xml i /wordpress/wp-includes/wlwmanifest.xml, a także /xmlrpc.php.

wlwmanifest.xml to manifest Windows Live Writer obecny w domyślnych instalacjach WordPressa, a odpytywanie o niego w popularnych katalogach to sposób na znajdowanie stron opartych na WordPressie przed próbami wykorzystania luk we wtyczkach lub motywach. XML-RPC to kolejny krok: badacze odkryli w 2015 r., że jego metoda system.multicall pozwala atakującemu wypróbować setki haseł w jednym żądaniu.

Pozostałości i elementy wewnętrzne

W porównaniu z poprzednimi trzema tygodniami liczba źródeł szukających plików kopii zapasowych i zrzutów wzrosła o 73%, celujących w wewnętrzne elementy aplikacji, takie jak Spring Boot actuator, o 63%, a żądających stron diagnostycznych, takich jak /phpinfo.php i /info.php, o 52%. Ponieważ wzrosła też ogólna liczba źródeł, ich udziały zmieniły się mniej: strony diagnostyczne przeszły ze średnio 15% wszystkich źródeł do 21%. Poniższy wykres pokazuje sześć kategorii z tego tygodnia, każdą z jej udziałem w źródłach w tym tygodniu na tle średniej z poprzednich trzech tygodni.

/actuator/env przyciągnął około 40 źródeł, 2.4 razy więcej, niż wynosiła jego wcześniejsza średnia. W Spring Boot ten punkt końcowy pokazuje właściwości konfiguracyjne aplikacji. Dokumentacja Springa podaje, że domyślnie przez HTTP dostępny jest tylko health, a wartości env są domyślnie maskowane, ale gdy programiści go udostępnią bez ograniczenia dostępu, może ujawniać dane uwierzytelniające, klucze API i ustawienia wewnętrzne. Liczba źródeł szukających /wp-config.php.bak, czyli zapomnianej kopii konfiguracji WordPressa, podwoiła się do około 40.

Drugi zestaw narzędzi z około 20 źródeł łączył te zainteresowania w jednym przebiegu: /.env, /.git/config, /info.php, /config.json, /server-status i /debug/default/view. Ostatnia ścieżka należy do debugera Yii 2, który pokazuje dane sesji, zmienne środowiskowe i zapytania do bazy danych. Przewodnik Yii podaje, że zwykle działa on tylko z localhost, ale CVE-2026-103475, ujawniona 30 września, dotyczy yii2-starter-kit do wersji 4.2.0 włącznie, której domyślna konfiguracja udostępnia debuger ze wszystkich adresów IP.

W nawiązaniu do zeszłego tygodnia

W poprzednim wydaniu odnotowaliśmy więcej skanerów szukających plików .env w podkatalogach. Ten trend się utrzymał. /v2/.env i /old/.env przyciągnęły po około 60 źródeł, mniej więcej dwa razy więcej niż ich wcześniejsza średnia, /production/.env 50, a /storage/.env 40. Łącznie pliki z sekretami i konfiguracją próbowało zdobyć 200 źródeł, o 16% więcej, czyli mniej więcej w tempie ogólnego wzrostu liczby źródeł, więc ich udział utrzymał się na poziomie 33%. Dla porównania skali: badacze poinformowali w lutym o 12,088,677 adresach IP udostępniających publicznie pliki w stylu .env.

Sondowanie repozytoriów Git, od którego zaczęliśmy zeszłotygodniowe wydanie, osłabło pod względem udziału, ale pozostało powyżej wcześniejszego poziomu. Łącznie 170 źródeł szukało repozytoriów kodu źródłowego, o 20% więcej niż średnia z trzech tygodni, choć ich udział we wszystkich źródłach spadł z 37% do 29%.

Kto pytał

Ponad połowa źródeł (55%) pochodziła z sieci chmurowych i hostingowych, przy czym DigitalOcean i Google Cloud miały po 20%, a 85% wszystkich źródeł pojawiło się tylko jednego dnia. Większość próbowała też udawać ludzi: 82% wysyłało identyfikatory podszywające się pod zwykłe przeglądarki, a jednak 85% zachowywało się jak automaty, więc to przebranie niewiele daje.

Co ucichło

Żądania /wp-content/plugins/hellopress/wp_filemanager.php, które pochodziły średnio od około 20 źródeł tygodniowo, prawie całkiem zanikły, spadając o 79%. Za wcześnie, by stwierdzić, czy skanery przerzuciły się na inne cele. Pliki kluczy chmurowych, takie jak /service-account.json, utrzymały się na mniej więcej stałym poziomie 70 źródeł.

Co zrobić

• Sprawdź wersję WordPressa. Jeśli mieści się w zakresie od 6.9.0 do 6.9.4 lub od 7.0.0 do 7.0.1, natychmiast zaktualizuj do 6.9.5 lub 7.0.2.
• Trzymaj pliki .env całkowicie poza katalogiem publicznym, także w starych wydaniach i wersjonowanych podkatalogach. Bezpiecznym miejscem jest poziom powyżej katalogu głównego serwera WWW.
• Usuń kopie zapasowe i zrzuty, takie jak /database.sql lub /wp-config.php.bak, ze wszystkich miejsc dostępnych z przeglądarki.
• Zabezpiecz elementy wewnętrzne. Ogranicz dostęp do punktów końcowych Spring Boot actuator i pozostaw włączone maskowanie env, usuń testowe strony phpinfo i ogranicz debuger Yii do localhost.
• Wyłącz XML-RPC, jeśli nic na Twojej stronie go nie potrzebuje.

O tych obserwacjach

Ten raport tworzy 291 Heat Seeker One, system monitorowania bezpieczeństwa 291 Group, działający na 291 Crossband, naszej autorskiej platformie operacji bezpieczeństwa. Obejmuje wyłącznie ruch kierowany do własnej, dostępnej z internetu infrastruktury 291 Group.

Liczby są zaokrąglone, udziały i zmiany mierzymy liczbą odrębnych źródeł, a nie żądań, i uwzględniamy tylko wzorce zaobserwowane z co najmniej 20 odrębnych źródeł. Kraje oznaczają lokalizację serwerów, z których pochodzą źródła, a niekoniecznie miejsce pobytu osób, które nimi zarządzają. Rodzaj sieci określamy na podstawie jej operatora; z nazwy wymieniamy wyłącznie dużych, dobrze znanych dostawców.