Każda strona na WordPress przechowuje w katalogu głównym „cichy" plik, o którym większość właścicieli dowiaduje się dopiero po ataku. Nazywa się xmlrpc.php. Sam w sobie nie jest szkodliwy: WordPress uczciwie ostrzega, że jest to interfejs do zdalnej komunikacji. Ale właśnie przez niego boty od lat próbują łamać hasła, rozsyłają spamowe pingbacki i generują ruch DDoS.

Według danych Wordfence za 2024 rok ataki przez XML-RPC należą do pięciu głównych wektorów ataków na strony WordPress. Jedno zapytanie system.multicall pozwala atakującemu sprawdzić setki haseł naraz, zamiast jednego, jak przez formularz logowania. Hostingi odnotowują miliony takich prób miesięcznie na przeciętnej stronie.

Przyjrzyjmy się, do czego ten plik w ogóle jest potrzebny, komu warto go zostawić, a przede wszystkim pokażemy pięć sposobów na wyłączenie lub skuteczne zablokowanie xmlrpc.php, od wtyczki na jedno kliknięcie po precyzyjną edycję .htaccess.

💡 Szybki przegląd:

• Dowiedz się, czym jest xmlrpc.php i jakie funkcje WordPress od niego zależą (pingback, aplikacja mobilna, Jetpack)
• Oceń realne ryzyko: amplifikacja brute-force, pingback-DDoS i skanowanie katalogów przez boty
• Wybierz odpowiedni sposób ochrony: wyłączenie wtyczką, blokada przez .htaccess, zamknięcie dostępu na poziomie serwera WWW lub usunięcie pliku
• Skonfiguruj monitoring: jak upewnić się, że xmlrpc.php przestał odpowiadać na zapytania

Czym jest xmlrpc.php i jakie funkcje WordPress od niego zależą

XML-RPC to protokół zdalnego wywoływania procedur, który działa na bazie HTTP i przesyła dane w formacie XML. Technologia pojawiła się pod koniec lat 90., na długo przed REST API, a WordPress odziedziczył ją u zarania swojego rozwoju. Plik xmlrpc.php w katalogu głównym strony przyjmuje zapytania XML, przetwarza je i zwraca odpowiedź, na przykład publikuje post, przesyła plik multimedialny lub sprawdza uprawnienia użytkownika.

W praktyce przez xmlrpc.php działa kilka scenariuszy:

• Pingbacki i trackbacki. Gdy ktoś linkuje do Pana/Pani posta, jego strona wysyła zapytanie XML-RPC z powiadomieniem. Pana/Pani WordPress sprawdza link i, jeśli jest prawdziwy, dodaje pingback do komentarzy.

• Zdalna publikacja. Aplikacje takie jak stary Windows Live Writer czy klienty desktopowe (TextMate, MarsEdit) używały XML-RPC do pisania i wysyłania postów bez wchodzenia do panelu administracyjnego.

• Aplikacja mobilna WordPress. Oficjalna aplikacja na iOS i Androida przez długi czas opierała się na XML-RPC, choć obecnie coraz aktywniej przechodzi na REST API.

• Integracje. Usługi takie jak Jetpack (część funkcjonalności), IFTTT i niektóre narzędzia SEO nadal używają XML-RPC do łączenia się ze stroną.

Wraz z wydaniem WordPress REST API w wersji 4.7 (grudzień 2016) większość nowoczesnych integracji przeniosła się na nowy protokół. REST API jest szybsze, działa z JSON zamiast XML i jest lepiej udokumentowane. Niemniej jednak WordPress nadal dołącza xmlrpc.php do każdej instalacji ze względu na kompatybilność wsteczną.

Ważny niuans: począwszy od WordPress 2.6 (jeszcze w 2008 roku) funkcjonalność zdalnej publikacji przez XML-RPC jest domyślnie wyłączona. Aby ją włączyć, trzeba jawnie zaznaczyć opcję w „Ustawienia → Pisanie". Pingbacki i trackbacki działają przy tym nadal.

Dlaczego xmlrpc.php jest niebezpieczny: trzy główne wektory ataków

Twórcy WordPress wielokrotnie łatili xmlrpc.php. W wersji 2.1.2 uwierzytelniony użytkownik z uprawnieniami „uczestnika" mógł opublikować post z pominięciem ograniczeń. W 2.3.1 wykryto wyciek informacji przez XML-RPC. Obie dziury szybko zamknięto, ale sam protokół pozostał architektonicznie podatny na trzy klasy ataków, aktualne również w 2026 roku.

Amplifikacja brute-force przez system.multicall

Główny problem to metoda system.multicall. Pozwala ona spakować w jednym zapytaniu HTTP wiele wywołań wp.getUsersBlogs. Każde wywołanie sprawdza parę „login + hasło". W ten sposób, zamiast jednego zgadywania na zapytanie, atakujący wykonuje ich setki. Cloudflare odnotowywał szczyty rzędu dziesiątek tysięcy takich zapytań na godzinę na jednej stronie.

Zwykły formularz logowania wp-login.php jest ograniczony do jednego loginu na próbę i łatwo go zabezpieczyć wtyczką taką jak Wordfence lub Limit Login Attempts. xmlrpc.php omija wszystkie te ograniczniki, ponieważ działa przez inny endpoint.

Pingback-DDoS

Funkcja pingbacków została pomyślana jako niewinne powiadomienie. Ale atakujący może wysłać sfałszowane zapytanie pingback w imieniu setek stron, a Pana/Pani serwer pójdzie sprawdzać każdy „link", obciążając procesor, sieć i bazę danych. Przy odpowiedniej skali strona pada. Sucuri w raporcie za 2023 rok nazywa ataki pingback jednym z najczęstszych wektorów DDoS przeciwko WordPress.

Skanowanie katalogów przez boty

Boty szukają xmlrpc.php nie tylko w katalogu głównym, ale także w zmyślonych podkatalogach, takich jak /2026/01/xmlrpc.php i /blog/xmlrpc.php. Każde takie zapytanie zwraca 404 i zużywa zasoby serwera. Nawet jeśli atak się nie powiedzie, dziesiątki tysięcy śmieciowych zapytań spowalniają stronę i zapychają logi. W praktyce właściciele widzą, jak wykresy w cPanel wchodzą w czerwoną strefę, a przyczyną są właśnie boty skanujące xmlrpc.php.

5 Sposobów na wyłączenie lub zabezpieczenie xmlrpc.php

Poniżej pięć metod, od najprostszej do najbardziej radykalnej. Proszę wybrać odpowiednią do swojej sytuacji: czy korzysta Pan/Pani z aplikacji mobilnej, czy potrzebne są pingbacki, jaki ma Pan/Pani hosting.

1. Wyłączyć przez wtyczkę

Najbezpieczniejsza droga dla tych, którzy nie chcą dotykać kodu. Proszę zainstalować wtyczkę, a ona zablokuje dostęp do xmlrpc.php na poziomie WordPress, zanim rozpocznie się przetwarzanie zapytania.

Plusy: nie trzeba edytować .htaccess ani functions.php; łatwo włączyć z powrotem. Minusy: dodaje kolejną wtyczkę w panelu administracyjnym; po dezaktywacji ochrona znika.

Kilka sprawdzonych opcji:

• Disable XML-RPC, minimalistyczna, jedno działanie: aktywacja i dostęp jest zamknięty. Żadnych ustawień.
• Wordfence Security, kompleksowa zapora sieciowa, w której wyłączenie XML-RPC to tylko jedna z funkcji. Sprawdzi się, jeśli już Pan/Pani korzysta z Wordfence lub planuje go zainstalować.

2. Zablokować przez.htaccess

Jeśli pracuje Pan/Pani na serwerze Apache, plik .htaccess w katalogu głównym strony pozwala zablokować dostęp, zanim zapytanie dotrze do WordPress. Zmniejsza to obciążenie: Apache zwraca 403 Forbidden natychmiast, bez uruchamiania PHP.

Proszę dodać w .htaccess następujący blok na początku pliku, przed # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

Dyrektywa RedirectMatch 403 przechwytuje każdy URL kończący się na /xmlrpc.php, włącznie z podkatalogami takimi jak /2025/06/xmlrpc.php, i natychmiast zwraca 403.

Plusy: nie dotyka kodu WordPress; działa przed załadowaniem PHP, oszczędza zasoby. Minusy: trzeba ręcznie edytować .htaccess; przy zmianie hostingu lub motywu plik może zostać nadpisany.

Ważne: przed edycją .htaccess proszę zrobić kopię zapasową. Błąd w składni .htaccess może położyć stronę (błąd 500 Internal Server Error).

3. Usunąć odnośnik przez functions.php

Ta metoda nie blokuje samego pliku, ale usuwa odnośniki HTML do xmlrpc.php i wlwmanifest.xml z sekcji <head> strony. Korzyść to zmniejszenie widoczności: boty parsujące HTML nie widzą bezpośredniego wskazania na endpoint XML-RPC.

Proszę dodać w functions.php aktywnego motywu (lub przez wtyczkę Code Snippets):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

Hook rsd_link wyprowadza <link rel="EditURI">, odnośnik do xmlrpc.php dla klientów Really Simple Discovery. Hook wlwmanifest_link dla Windows Live Writer (dawno nieobsługiwany, ale WordPress nadal go wyprowadza).

Plusy: czysty <head> bez śmieciowych odnośników. Minusy: xmlrpc.php fizycznie pozostaje dostępny pod bezpośrednim URL; to nie blokada, a maskowanie.

4. Zamknąć dostęp przez WAF lub Cloudflare

Web Application Firewall (zapora aplikacji webowych) blokuje zapytania do xmlrpc.php jeszcze zanim dotrą one do Pana/Pani serwera. To najskuteczniejsze podejście dla stron na dowolnym hostingu.

Opcje konfiguracji:

• Cloudflare (darmowy plan): Reguła WAF → Block → pole URI Path zawiera /xmlrpc.php. Zapytanie jest odbijane na poziomie sieci Cloudflare, Pana/Pani serwer nawet go nie widzi.
• Wordfence WAF: Wbudowana funkcja „Disable XML-RPC" w sekcji zapory.
• WAF hostingowe: Kinsta, WP Engine i inne zarządzane hostery pozwalają wyłączyć XML-RPC na kilka kliknięć przez panel sterowania.

Plusy: zerowe obciążenie serwera; można precyzyjnie skonfigurować (na przykład zezwolić Jetpack, blokując całą resztę). Minusy: wymagana konfiguracja po stronie WAF; nie wszystkie hostingi oferują taką możliwość.

5. Usunąć lub zmienić nazwę samego pliku

Najbardziej radykalna metoda. Usuwa Pan/Pani (lub zmienia nazwę) pliku xmlrpc.php z serwera. Jeśli pliku fizycznie nie ma, nie ma czemu obsługiwać zapytań, serwer zwraca 404.

Ważny niuans: przy następnej aktualizacji WordPress plik zostanie przywrócony. Automatyczne aktualizacje rdzenia nadpisują wszystkie pliki WordPress, włącznie z xmlrpc.php. Dlatego usunięcie to środek tymczasowy, chyba że skonfiguruje Pan/Pani regularne czyszczenie.

Jeśli idzie Pan/Pani tą drogą, proszę uzupełnić usunięcie regułą .htaccess ze sposobu 2. Bez niej boty będą nadal pukać pod URL xmlrpc.php, a serwer będzie sumiennie zwracał 404 na każde zapytanie, generując tysiące błędów w logach.

Czy w ogóle warto wyłączać xmlrpc.php?

Odpowiedź zależy od tego, z czego Pan/Pani korzysta. Proszę przejść przez listę kontrolną:

Jeśli nie korzysta Pan/Pani ze starej wersji aplikacji mobilnej, nie włączał/a Pan/Pani zarządzania Jetpack z WordPress.com i pingbacki nie są dla Pana/Pani krytyczne, proszę śmiało wyłączać. W 2026 roku REST API pokrywa praktycznie wszystkie realne scenariusze.

Wideo: jak wyłączyć XML-RPC w WordPress w 5 minut

Proszę obejrzeć poglądową instrukcję wyłączania xmlrpc.php, z demonstracją ekranu i wyjaśnieniem każdej metody:

⁉️🤔 Często zadawane pytania

Czy bezpiecznie jest po prostu ignorować xmlrpc.php?

W większości przypadków nie. Nawet jeśli nie używa Pan/Pani XML-RPC, boty skanują ten endpoint nieustannie. Każde takie zapytanie obciąża serwer. Lepiej jawnie zamknąć dostęp przez .htaccess lub wtyczkę, to eliminuje zarówno ryzyko brute-force, jak i śmieciowe zapytania w logach.

Czy strona się zepsuje, jeśli wyłączę xmlrpc.php?

Sam WordPress będzie nadal działać bez zmian. Proszę tylko sprawdzić, czy nie korzysta Pan/Pani z zarządzania Jetpack przez WordPress.com lub starej wersji aplikacji mobilnej. Jeśli nie, proszę wyłączać bez obaw. Pingbacki przestaną przychodzić, ale większość stron i tak nie używa ich do realnej komunikacji.

Jak sprawdzić, czy xmlrpc.php jest rzeczywiście zablokowany?

Proszę otworzyć w przeglądarce https://ваш-сайт.ru/xmlrpc.php. Jeśli widzi Pan/Pani biały ekran z komunikatem „XML-RPC server accepts POST requests only", plik jest aktywny i odpowiada. Jeśli otrzymuje Pan/Pani 403 Forbidden lub 404 Not Found, blokada działa. Do automatycznego monitorowania można użyć internetowych checkerów, takich jak xmlrpc.eror.xyz, lub zapytania curl z konsoli.

Co jest lepsze: wtyczka czy.htaccess?

.htaccess blokuje zapytanie przed uruchomieniem WordPress, co oszczędza zasoby serwera. Wtyczkę łatwiej zainstalować i nie wymaga edycji plików. Dla stron niekrytycznych różnica jest prawie niezauważalna. Dla projektów o wysokim obciążeniu lepszy jest .htaccess lub reguła WAF.

Czy trzeba aktualizować WordPress po wyłączeniu xmlrpc.php?

Nie. Wyłączenie xmlrpc.php nie zależy od wersji WordPress i nie wpływa na aktualizacje rdzenia. Jedyny niuans: jeśli usunął Pan/Pani plik fizycznie, aktualizacja go przywróci, konieczne będzie ponowne usunięcie.

Co więc zrobić z xmlrpc.php na Pana/Pani stronie?

Nie ma uniwersalnej odpowiedzi, wszystko zależy od kontekstu. Ale praktyka tysięcy stron na WordPress daje jasny obraz: jeśli nie wie Pan/Pani, czy potrzebuje Pan/Pani XML-RPC, to go Pan/Pani nie potrzebuje.

Jeśli chce Pan/Pani niezawodności bez zagłębiania się w kod, proszę zainstalować Disable XML-RPC. Jeśli gotów jest Pan/Pani poświęcić pięć minut na .htaccess, otrzyma Pan/Pani ochronę na poziomie serwera, bez zbędnych wtyczek. Jeśli korzysta Pan/Pani z Cloudflare, proszę skonfigurować regułę WAF i zapomnieć o problemie.

Najważniejsze, by nie zostawiać xmlrpc.php otwartego „domyślnie". W 2026 roku każdy niezamknięty endpoint WordPress to cel dla automatycznych botów, którym jest obojętne, czy ma Pan/Pani blog, czy sklep internetowy. Proszę zamknąć dostęp jednym ze sposobów powyżej, sprawdzić wynik zapytaniem curl i spać spokojnie.