XML-RPC

XML-RPC to protokół zdalnego wywoływania procedur działający przez internet: wiadomość jest żądaniem HTTP POST, a jej treść zapisana jest w XML ^[1]. Specyfikację opublikował Dave Winer 15 czerwca 1999 roku ^[1]. W WordPressie protokół obsługuje plik xmlrpc.php, przez który zewnętrzne aplikacje mogą publikować wpisy, wgrywać media i zarządzać komentarzami. Dla bezpieczeństwa ważne jest to, że plik jest publicznie dostępny, przyjmuje dane logowania i potrafi wysyłać żądania do innych serwerów.

Jak działa

Klient wysyła do serwera dokument XML z nazwą metody i jej parametrami, a serwer odpowiada wynikiem albo kodem błędu. Interfejs XML-RPC w WordPressie zastąpił starsze interfejsy Blogger, MovableType i metaWeblog ^[2]. Obejmuje wpisy, taksonomie, media, komentarze, opcje i użytkowników ^[2]. Nowszym kanałem jest REST API, wymieniające dane w formacie JSON; jego słabości opisuje hasło niezabezpieczony endpoint REST API.

Szczególną metodą jest system.multicall. Pozwala ona zmieścić wiele wywołań w jednym żądaniu: serwer przechodzi po liście i wykonuje je kolejno ^[7]. Z tej samej właściwości korzystają atakujący, bo jedno żądanie HTTP może nieść wiele prób logowania. Dokumentacja WordPressa wskazuje xmlrpc.php, a zwłaszcza system.multicall, jako częsty cel ataków siłowych (brute-force) ^[4].

RYS. 1Próby logowania w jednym żądaniu system.multicall

Schemat pokazuje zachowanie obecnego kodu rdzenia. Po pierwszym nieudanym logowaniu serwer XML-RPC ustawia flagę auth_failed, a każda następna próba w tym samym żądaniu kończy się błędem bez sprawdzania hasła ^[6]. Nie chroni to przed atakiem rozłożonym na wiele żądań, dlatego nadal potrzebny jest limit prób logowania.

W WordPressie

WordPress ma filtr xmlrpc_enabled, dostępny od wersji 3.5.0 i domyślnie ustawiony na true ^[3]. Dokumentacja podkreśla, że filtr nie wyłącza XML-RPC w całości. Steruje tylko metodami wymagającymi uwierzytelnienia i nie wpływa na pingbacki ani na metody bez logowania ^[3]. Pełne odcięcie wymaga blokady pliku na serwerze albo WAF przed stroną. Przegląd dostępnych sposobów zawiera tabela.

Przykład blokady w konfiguracji Apache, stosowanej na przykład jako jedno z zabezpieczeń w .htaccess:

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

Przed blokadą warto sprawdzić, czy z interfejsu nie korzysta aplikacja mobilna, narzędzie do publikacji albo integracja. Dokumentacja WordPressa zaleca wyłączenie XML-RPC, jeśli nie jest używany ^[4].

Zagrożenia i skutki

Zgadywanie haseł. Ataki na xmlrpc.php są zautomatyzowane i często rozproszone przez botnety, więc nawet nieudane próby mogą przeciążyć stronę ^[4]. Skuteczny atak kończy się przejęciem konta, a przy koncie administratora przejęciem całej strony.

Pingback jako broń. Mechanizm pingbacków sprawia, że WordPress sam wysyła żądanie pod adres podany w wywołaniu XML-RPC ^[8]. Niebezpiecznik 11 marca 2014 roku opisał atak DDoS, w którym użyto 76 773 unikatowych blogów WordPress, w tym 39 z Polski ^[8]. Według tego opisu każdy mógł wymusić na dowolnym WordPressie wysłanie złośliwego żądania przez interfejs XML-RPC ^[8]. Strona staje się wtedy narzędziem ataku na cudzy serwer: atakujący wysyła po jednym żądaniu do wielu blogów, a każdy z nich kieruje ruch do ofiary.

Wyciek informacji. Sekurak 21 maja 2025 roku opisał technikę badaczy z firmy Imperva, która przez fałszywe pingbacki pozwala poznawać tytuły szkiców i prywatnych wpisów ^[5]. Atakujący wysyła żądania XML-RPC z adresami zawierającymi fragment tytułu. Jeśli fragment pasuje, serwer ofiary wykonuje żądanie do serwera atakującego, a jeśli nie pasuje, nie wykonuje go ^[5]. Dokładając kolejne znaki, można odtworzyć cały tytuł; zamiast żądania zwrotnego da się też mierzyć czas odpowiedzi ^[5]. Technika działa w domyślnej instalacji, bez logowania ^[5]. To przykład ujawnienia informacji przez funkcję, która sama w sobie nie jest błędem.

Zbędna powierzchnia. Interfejs, z którego nikt nie korzysta, a który przyjmuje dane logowania, powiększa powierzchnię ataku bez żadnego pożytku.

Jak się bronić

• Ustalić, czy XML-RPC jest potrzebny. Jeśli nie, wyłączyć go ^[4], najlepiej na poziomie serwera, bo sam filtr xmlrpc_enabled nie obejmuje pingbacków ^[3].
• Jeśli interfejs musi działać, usunąć metodę pingback.ping, co zalecano już w 2014 roku ^[8], albo wyłączyć pingbacki w ustawieniach ^[5].
• Ograniczać próby logowania na poziomie serwera lub brzegu sieci, a nie tylko w panelu. Dokumentacja WordPressa zaleca, by tam, gdzie to możliwe, ograniczać żądania na brzegu sieci albo na serwerze, a nie wtyczką, ze względu na zużycie zasobów przy dużym ataku ^[4].
• Włączyć uwierzytelnianie dwuskładnikowe (two-factor authentication, 2FA) dla kont z uprawnieniami administratora ^[4].
• Przeglądać logi serwera pod kątem żądań POST do /xmlrpc.php ^[8], na przykład w ramach retencji logów.

Przykład usunięcia metody pingback filtrem w PHP:

add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Historia i przykłady

Protokół powstał w 1999 roku, a jego specyfikacja opisuje implementację w UserLand Frontier 5.1 ^[1]. W WordPressie zastąpił starsze interfejsy blogowe ^[2]. Atak DDoS z marca 2014 roku ^[8] i opisana w 2025 roku technika odczytu tytułów ^[5] pokazały, że interfejs przeznaczony do wymiany informacji między blogami może posłużyć zarówno do zmasowanego ataku na zewnętrzny serwer, jak i do wydobycia danych z samej strony.