WordPress od wielu lat umożliwia zdalną komunikację z witryną, a przez długi czas centralnym elementem tej funkcji był plik xmlrpc.php. Choć kiedyś pełnił ważną rolę w integracji zewnętrznych aplikacji i usług, dziś coraz częściej kojarzony jest z zagrożeniami niż z realną użytecznością.

W tym artykule przyjrzymy się bliżej, czym tak naprawdę jest plik xmlrpc.php, w jakim celu został wprowadzony i jaką funkcję pierwotnie miał spełniać. Omówimy również typowe problemy bezpieczeństwa, jakie generuje, oraz przedstawimy skuteczne sposoby na ich eliminację lub ograniczenie na własnej instalacji WordPressa.

Co to jest xmlrpc.php ?

XML-RPC w WordPressie to mechanizm umożliwiający wymianę danych, w którym HTTP pełni rolę kanału przesyłowego, a XML odpowiada za formatowanie informacji. Funkcja ta powstała z myślą o tym, by WordPress – jako otwarta platforma – mógł swobodnie komunikować się z zewnętrznymi aplikacjami i systemami.

Geneza powstania xmlrpc.php

XML-RPC to jedna z najstarszych funkcji obecnych w WordPressie – jej początki sięgają czasów, gdy system ten dopiero raczkował i nie nosił jeszcze swojej dzisiejszej nazwy.

W erze wolnych łączy internetowych publikowanie treści online było uciążliwe i często wiązało się z wieloma ograniczeniami. Aby ułatwić życie blogerom, powstały aplikacje umożliwiające tworzenie wpisów offline, które można było później przesłać na bloga po uzyskaniu dostępu do internetu. Właśnie do obsługi takiej komunikacji służył XML-RPC.

Początkowo funkcja ta była domyślnie wyłączona, a użytkownik mógł samodzielnie zdecydować o jej aktywacji. W wersji WordPress 2.6 pojawiła się możliwość zarządzania XML-RPC bezpośrednio z poziomu kokpitu. Jednak wraz z wprowadzeniem WordPressa 3.5 oraz oficjalnej aplikacji mobilnej, sytuacja się zmieniła – XML-RPC został automatycznie aktywowany, a opcja jego wyłączenia została usunięta z panelu administracyjnego, co wywołało mieszane reakcje wśród użytkowników.

Do czego służy plik xmlrpc.php?

Jego głównym zadaniem było umożliwienie zdalnego dostępu do strony. W praktyce wykorzystywano go m.in. do:

• zarządzania stroną z poziomu urządzenia mobilnego, np. dodawania wpisów przez aplikację WordPress,
• obsługi tzw. trackbacków i pingbacków, czyli automatycznych powiadomień o tym, że inna strona odwołała się do naszej treści,
• współpracy z wtyczką Jetpack, która za pomocą xmlrpc.php oferowała takie funkcje jak statystyki czy podstawowe zabezpieczenia przed atakami siłowymi (brute force).

Przykład zastosowania:
Jeśli użytkownik chciał opublikować artykuł bezpośrednio z telefonu, plik xmlrpc.php pozwalał na zdalne połączenie z witryną i wykonanie tej akcji – bez potrzeby logowania się przez przeglądarkę.

Obecna rola XML-RPC

W 2015 roku WordPress zaczął wdrażać nowoczesne REST API, które z czasem przejęło większość zadań wcześniej realizowanych przez XML-RPC, szczególnie w zakresie komunikacji z aplikacjami mobilnymi i zewnętrznymi usługami. Mimo tego plik xmlrpc.php wciąż znajduje się w głównym katalogu WordPressa i pozostaje domyślnie aktywny, choć jego znaczenie wyraźnie zmalało.

Czy warto wyłączyć xmlrpc.php? Zdecydowanie tak – i oto dlaczego.

Chociaż sam protokół XML-RPC nie został zaprojektowany jako luka bezpieczeństwa, to jego implementacja w WordPressie stwarza wiele możliwości dla potencjalnych ataków. Z tego względu zaleca się jego wyłączenie, szczególnie jeśli nie korzystasz aktywnie z funkcji, które go wymagają.

Brute force w nowym wydaniu

Jednym z najpoważniejszych zagrożeń są zautomatyzowane ataki brute force na ekran logowania. Dzięki metodzie system.multicall możliwe jest wysłanie setek prób logowania w jednym żądaniu, co skutecznie omija zabezpieczenia ograniczające liczbę prób czy blokujące podejrzane logowania za pomocą CAPTCHA.

DDoS z użyciem pingbacków

Innym niebezpieczeństwem są ataki DDoS wykorzystujące funkcję pingback. Hakerzy mogą wysyłać tysiące żądań pingbacków, które zmuszają Twój serwer do komunikowania się z innymi witrynami – często jednocześnie. To przeciąża zasoby i może doprowadzić do tymczasowego (lub długotrwałego) unieruchomienia strony.

Spam i inne nadużycia

Przy aktywnym XML-RPC boty mogą próbować publikować spamerskie treści lub wykorzystywać protokół do nieautoryzowanego dostępu do danych. Choć brzmi to jak scenariusz z filmu science fiction, takie przypadki były już notowane.

Jak wyłączyć xmlrpc.php w WordPress?

Istnieje kilka skutecznych metod dezaktywacji pliku xmlrpc.php, które zwiększą bezpieczeństwo Twojej strony. Oto najlepsze rozwiązania:

Wyłączenie za pomocą wtyczki (najprostsza metoda)

Najszybszy sposób to użycie specjalnych wtyczek, np. Disable XML-RPC – całkowicie blokuje dostęp do xmlrpc.php.

Gotowe! Działająca wtyczka Disable XML-RPC skutecznie blokuje tę funkcję, nie wymagając dodatkowych działań z Twojej strony.

Wyłączenie XML-RPC poprzez plik functions.php motywu

Jednym z najprostszych i zarazem najbezpieczniejszych sposobów na dezaktywację XML-RPC w WordPressie jest dodanie odpowiedniego fragmentu kodu do pliku functions.php używanego motywu. Rozwiązanie to nie wymaga instalowania dodatkowych wtyczek ani grzebania w plikach systemowych – wystarczy edytować jeden plik w ramach aktualnie aktywnego motywu.

Jak to zrobić krok po kroku?

1. Zaloguj się do panelu administracyjnego WordPressa.

2. Przejdź do Wygląd → Edytor plików motywu (Theme File Editor).

3. Wybierz po lewej stronie plik functions.php.

4. Na końcu pliku (ale przed znakiem ?>, jeśli taki występuje), dodaj następujący kod:

5. Zapisz zmiany klikając przycisk Zaktualizuj plik.

Ręczne wyłączenie XML-RPC przez .htaccess (dla serwera Apache)

Jeśli Twój WordPress działa na serwerze Apache, możesz całkowicie zablokować dostęp do pliku xmlrpc.php na poziomie serwera — zanim jeszcze żądanie trafi do samego WordPressa. Jest to skuteczna metoda ochrony, ponieważ eliminuje ryzyko wykorzystania tej funkcji przez zewnętrznych atakujących.

1. Zaloguj się do swojego serwera za pomocą klienta FTP lub menedżera plików w panelu hostingowym.

2. Przejdź do katalogu głównego WordPressa (tam, gdzie znajduje się plik wp-config.php).

3. Odszukaj plik .htaccess. Jeśli go nie widzisz, upewnij się, że masz włączone wyświetlanie ukrytych plików.

4. Zrób kopię zapasową pliku przed edycją!

5. Dodaj na końcu pliku następujący fragment:

<files xmlrpc.php> 
order allow,deny 
deny from all </files>

6. Zapisz plik i zamknij edytor.

Instrukcja <Files> nakazuje serwerowi całkowicie zablokować dostęp do pliku xmlrpc.php. Oznacza to, że jakiekolwiek próby jego wywołania – niezależnie czy z zewnątrz, czy przez jakąkolwiek usługę – zostaną odrzucone już na poziomie serwera, bez angażowania WordPressa.

Blokada dostępu do xmlrpc.php w konfiguracji Nginx

Jeśli Twój serwer korzysta z Nginx, sposób działania jest nieco inny – zamiast pliku .htaccess, zmiany wprowadza się bezpośrednio w pliku konfiguracyjnym serwera.

1. Zaloguj się do serwera i otwórz plik konfiguracyjny Nginx odpowiedzialny za Twoją stronę (np. /etc/nginx/sites-available/twojastrona.pl).

2. W obrębie bloku server { ... }, dodaj poniższy kod:

location = /xmlrpc.php {
    deny all;
}

3. Zapisz zmiany i uruchom ponownie serwer Nginx komendą:

Ten fragment konfiguracji mówi Nginxowi, że każde żądanie skierowane dokładnie do pliku xmlrpc.php ma zostać odrzucone — użytkownik otrzyma kod błędu HTTP 403 Forbidden.

Podsumowanie

Niezależnie od tego jaką metodę wykorzystasz, blokowanie dostępu do xmlrpc.php  jest jedną z najbardziej efektywnych metod zabezpieczenia strony WordPress. Dzięki temu unikniesz nadmiernego obciążenia, ataków brute force i innych zagrożeń, a Twoja strona będzie działać szybciej i bezpieczniej. Jeśli nie korzystasz z funkcji zdalnej publikacji lub Jetpacka — warto tę funkcję całkowicie wyłączyć.