Wiele stron na WordPressie działa latami bez większych problemów. Właściciele instalują motyw, kilka wtyczek, konfigurują formularz kontaktowy i uznają temat za zamknięty. Problem w tym, że WordPress domyślnie posiada funkcje, które dziś dla większości stron są kompletnie zbędne — a jednocześnie mogą stać się furtką do ataków.
Jedną z nich jest właśnie XML-RPC.
Co to jest XML-RPC?
XML-RPC to stary mechanizm komunikacji z WordPressem przez zewnętrzne aplikacje. Kiedyś był potrzebny np. do:
publikowania wpisów z telefonu,
integracji z niektórymi aplikacjami,
zdalnego zarządzania WordPressem.
Dziś większość nowoczesnych rozwiązań korzysta już z REST API, a XML-RPC w wielu przypadkach pozostaje po prostu niepotrzebnym, aktywnym wejściem do strony.
Adres wygląda zazwyczaj tak:
twojastrona.pl/xmlrpc.php
I właśnie ten plik bardzo często staje się celem botów.
Dlaczego XML-RPC jest niebezpieczne?
1. Ataki brute force na logowanie
XML-RPC pozwala wykonywać próby logowania poza standardowym formularzem WordPressa.
To oznacza, że:
bot może próbować tysiące haseł,
często omija podstawowe zabezpieczenia logowania,
obciąża serwer,
może doprowadzić do przejęcia konta.
W logach serwera często wygląda to tak:
POST /xmlrpc.php
setki lub tysiące razy dziennie.
2. Ataki DDoS i pingback
XML-RPC posiada funkcję pingback, która była kiedyś używana do powiadamiania innych blogów o linkach.
Dziś bywa wykorzystywana do:
wzmacniania ataków DDoS,
generowania sztucznego ruchu,
przeciążania serwerów.
Twoja strona może nawet nieświadomie brać udział w ataku na inne strony.
3. Niepotrzebne obciążenie hostingu
Na wielu stronach XML-RPC jest regularnie skanowane przez:
boty SEO,
skanery podatności,
automatyczne narzędzia hakerskie,
AI crawlery.
Efekt?
większe zużycie CPU,
więcej procesów PHP,
wolniejsza strona,
problemy na tańszym hostingu.
Czasami właściciel strony myśli, że „hosting jest słaby”, a problemem jest po prostu brak podstawowych zabezpieczeń.
Skąd wiedzieć, czy XML-RPC jest aktywne?
Wejdź w przeglądarce na:
twojadomena.pl/xmlrpc.php
Jeśli zobaczysz komunikat podobny do:
XML-RPC server accepts POST requests only.
to oznacza, że funkcja jest aktywna.
Czy można to bezpiecznie wyłączyć?
W większości przypadków — TAK.
Jeśli:
nie korzystasz z aplikacji mobilnej WordPress,
nie używasz Jetpacka,
nie masz specjalnych integracji,
to XML-RPC najczęściej można wyłączyć całkowicie.
Jak wyłączyć XML-RPC?
Opcja 1 — Cloudflare (najlepsze)
Jeśli używasz Cloudflare, możesz po prostu zablokować dostęp regułą WAF.
Przykładowa reguła:
(http.request.uri.path contains "/xmlrpc.php")
Akcja:
Block
To najbezpieczniejsze rozwiązanie, bo ruch zostaje zatrzymany jeszcze przed serwerem.
Opcja 2 — .htaccess
Dodaj do .htaccess:
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
Opcja 3 — wtyczka WordPress
Istnieją wtyczki typu:
Disable XML-RPC,
Disable XML-RPC Pingback.
Ale lepiej blokować to na poziomie serwera lub Cloudflare.
Uwaga: niektóre wtyczki nadal tego używają
Przed całkowitym wyłączeniem warto sprawdzić:
Jetpack,
aplikacje mobilne,
zewnętrzne systemy publikacji,
niektóre integracje WooCommerce.
Na większości zwykłych stron firmowych XML-RPC jest jednak kompletnie zbędne.
Jak sprawdzić, czy ktoś atakuje XML-RPC?
W logach serwera lub Cloudflare często pojawiają się wpisy:
POST /xmlrpc.php
Jeśli widzisz:
dużą liczbę takich żądań,
ruch z różnych krajów,
dziwne boty,
to prawdopodobnie Twoja strona jest regularnie skanowana.
I najczęściej dzieje się to codziennie.
Problem większy niż myślisz
Wiele stron WordPress:
nie ma aktualizacji,
ma stare wtyczki,
ma słabe hasła,
ma aktywne XML-RPC,
nie ma żadnego WAF.
To idealny cel dla automatycznych botów.
Co gorsza — właściciel często dowiaduje się o problemie dopiero wtedy, gdy:
hosting blokuje konto,
strona zaczyna działać wolno,
pojawia się malware,
Google oznacza stronę jako niebezpieczną.
Podsumowanie
XML-RPC to jedna z tych funkcji WordPressa, które były potrzebne wiele lat temu, ale dziś dla większości stron są tylko niepotrzebnym ryzykiem.
Jeśli prowadzisz stronę na WordPressie:
sprawdź, czy XML-RPC jest aktywne,
przeanalizuj logi,
zablokuj dostęp,
najlepiej zabezpiecz stronę przez WAF lub Cloudflare.
Czasem jedna mała reguła potrafi znacząco zmniejszyć ilość ataków i obciążenie serwera.
