Dlaczego xmlrpc.php to otwarte drzwi do Twojego WordPressa

xmlrpc.php to pozostałość po czasach, gdy WordPress rozmawiał z aplikacjami mobilnymi i edytorami zewnętrznymi przez protokół XML-RPC. Dziś zastępuje go REST API, ale plik nadal jest w każdej instalacji i domyślnie odpowiada na żądania.

Co w nim jest groźnego

Dwie metody robią różnicę:

• system.multicall pozwala zapakować wiele wywołań w jedno żądanie HTTP. Atakujący wysyła jedno żądanie z pięciuset parami login/hasło, a serwer grzecznie sprawdza wszystkie. Limity prób logowania w wtyczkach bezpieczeństwa zwykle liczą żądania, nie próby, więc nic nie widzą.
• pingback.ping każe stronie odwiedzić dowolny adres. Tysiąc stron WordPress z otwartym xmlrpc to gotowa sieć do amplifikacji ataku DDoS na kogoś trzeciego. Twoja strona staje się narzędziem, a Twój adres IP trafia na czarne listy.

Jak to wykrywa CREATO_PING

Sonda wysyła żądanie POST /xmlrpc.php z metodą system.listMethods. Jeśli serwer odpowiada kodem 200 i listą metod zawierającą system.multicall, powstaje ustalenie exposure_xmlrpc o ważności wysokiej i pewności ewidentnej. Strona przechodzi w status PODATNA.

Dlaczego „podatna", a nie „zainfekowana"? Bo otwarty xmlrpc to drzwi, nie włamanie. W parze z enumeracją użytkowników (/wp-json/wp/v2/users zdradza login administratora) atakujący ma już połowę danych do logowania. Wtedy dwa ustalenia razem opisują pełny łańcuch brute-force.

Co zrobić

1. Jeśli nie używasz aplikacji WordPress na telefon ani Jetpacka, zablokuj plik w całości. Reguła w .htaccess:

<Files xmlrpc.php>
  Require all denied
</Files>

2. Jeśli musisz zostawić xmlrpc, wyłącz same metody system.multicall i pingback.ping filtrem xmlrpc_methods.
3. Zablokuj enumerację użytkowników: ?author=1 i endpoint users w REST API dla niezalogowanych.
4. Zmień login admin na coś, czego nie da się zgadnąć.

Po naprawie kolejny skan zamyka ustalenie automatycznie, a strona wraca do statusu Działa.