Strona działa wolno, dostawca hostingu wysyła ostrzeżenie o przekroczeniu limitów, a w logach widnieje niekończąca się lista żądań POST do xmlrpc.php. Jeśli administruje Pan/Pani WordPressem, ten koszmar jest Panu/Pani z pewnością znany.

Plik xmlrpc.php to cichy, ale niezwykle niebezpieczny element każdej instalacji WordPressa. Znajduje się w katalogu głównym Pana/Pani witryny od momentu instalacji CMS i od dziesięcioleci pozostaje ulubionym punktem wejścia dla botów i cyberprzestępców. Według raportu Wordfence za 2024 rok ataki przez XML-RPC należą do pięciu głównych wektorów zagrożeń dla witryn WordPress i w 2026 roku nic się nie zmieniło.

Mimo to większość właścicieli witryn nie ma pojęcia, po co ten plik w ogóle istnieje i jak go unieszkodliwić. W tym poradniku przedstawiamy cztery skuteczne sposoby na zablokowanie xmlrpc.php: od szybkiej reguły w .htaccess po zaporę na poziomie CDN. Bez lania wody, ze sprawdzonym kodem i wyjaśnieniem, którą metodę kiedy zastosować.

💡 Szybki przegląd:

• Proszę sprawdzić, czy Pana/Pani xmlrpc.php odpowiada na żądania POST: najprawdopodobniej tak
• Proszę wybrać sposób blokowania: htaccess, kod w functions.php, wtyczka lub WAF
• Proszę dodać regułę blokowania i upewnić się, że endpoint zwraca 403 Forbidden
• Jeśli korzysta Pan/Pani z Jetpacka, proszę skonfigurować punktową ochronę przez zaporę zamiast całkowitego wyłączania

Czym jest xmlrpc.php i dlaczego wciąż jest w WordPressie

XML-RPC (Remote Procedure Call) to protokół umożliwiający zewnętrznym aplikacjom komunikację z WordPressem. Pojawił się w jądrze już w wersji 1.5 i przez dziesięciolecia służył jako jedyne API do zdalnej publikacji: za jego pośrednictwem działały aplikacje mobilne WordPressa, klienci desktopowi, tacy jak Windows Live Writer, oraz usługi zewnętrzne.

Wraz z wydaniem WordPress REST API w wersji 4.7 (2016 rok) potrzeba korzystania z XML-RPC praktycznie zniknęła. Nowoczesne REST API pokrywa wszystko, co wcześniej robił XML-RPC, i robi to bezpieczniej, szybciej oraz z normalnym uwierzytelnianiem przez nonce lub OAuth.

Jednak plik xmlrpc.php wciąż znajduje się w katalogu głównym każdej instalacji WordPressa. Domyślnie zdalna publikacja za jego pośrednictwem jest wyłączona, ale sam endpoint przyjmuje żądania. Wystarczy otworzyć вашсайт.com/xmlrpc.php w przeglądarce, aby zobaczyć: „XML-RPC server accepts POST requests only". Oznacza to, że endpoint jest aktywny i gotowy na atak.

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

Cyberprzestępcy wykorzystują xmlrpc.php do dwóch głównych typów ataków i oba mogą położyć Pana/Pani witrynę.

Brute force przez system.multicall. Metoda system.multicall pozwala spakować w JEDNO żądanie HTTP setki prób autoryzacji. Zamiast sprawdzać hasła pojedynczo (jak przez wp-login.php), bot wysyła tablicę loginów i haseł razem. Zwykłe wtyczki ograniczające próby logowania (login limiters) nie widzą takiego żądania: dla nich to „jedna próba". Rezultat: napastnik sprawdza tysiące kombinacji w kilka sekund, nie podlegając blokadzie.

Pingback DDoS. Funkcja pingbacków umożliwia innej witrynie powiadomienie Pana/Pani WordPressa o linku do niego. Napastnik wysyła sfałszowane żądanie pingback, podstawiając jako „źródło" adres IP ofiary. Pana/Pani serwer sumiennie idzie sprawdzić link i atakuje niczego niepodejrzewający host docelowy. Proszę to przeskalować na tysiące skompromitowanych instalacji WordPressa: powstaje rozproszony atak DDoS, w którym Pana/Pani witryna służy jako mięso armatnie.

Dostawcy hostingu monitorują tego rodzaju ruch wychodzący i mogą zamrozić konto za „udział w DDoS". A sam serwer w tym czasie zużywa procesor, pamięć i transfer na obsługę śmieciowych żądań.

Proszę sprawdzić: czy Pana/Pani xmlrpc.php odpowiada

Przed zablokowaniem proszę się upewnić, że endpoint jest rzeczywiście otwarty. Proszę otworzyć w przeglądarce:

1
https://вашсайт.com/xmlrpc.php

Jeśli widzi Pan/Pani komunikat „XML-RPC server accepts POST requests only", endpoint jest aktywny i napastnicy mogą wysyłać do niego żądania. Jeśli otrzymuje Pan/Pani 403 Forbidden lub 404, ochrona już działa.

Drugi sposób to wysłanie testowego żądania POST przez terminal:

1
curl -X POST https://вашсайт.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Odpowiedź z 200 OK i strukturą XML potwierdza: XML-RPC przyjmuje żądania i jest gotowy do eksploatacji.

Sposób 1: szybkie blokowanie przez.htaccess

Najprostsza i najskuteczniejsza metoda to zablokowanie dostępu do pliku na poziomie serwera WWW. Żądanie jest odrzucane, zanim dotrze do WordPressa, co oszczędza zasoby serwera i działa, nawet gdy witryna jest pod obciążeniem.

Proszę dodać w głównym .htaccess (tym obok wp-config.php):

1
Блокировка xmlrpc.php — защита от brute force и DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Dyrektywa Require all denied to składnia Apache 2.4+, aktualna dla wszystkich nowoczesnych hostingów. Po zapisaniu proszę otworzyć xmlrpc.php w przeglądarce: powinien Pan/Pani otrzymać 403 Forbidden.

Jeśli serwer działa na nginx, regułę dodaje się w konfiguracji wirtualnego hosta:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Po zmianie konfiguracji nginx proszę nie zapomnieć przeładować serwer: sudo nginx -s reload.

Ta metoda jest odpowiednia, jeśli NA PEWNO nie potrzebuje Pan/Pani XML-RPC: ani do Jetpacka, ani do aplikacji mobilnych WordPressa, ani do integracji z WooCommerce.

Sposób 2: wyłączenie przez functions.php (metoda programowa)

Jeśli woli Pan/Pani rozwiązać problem na poziomie kodu, a nie konfiguracji serwera, oto dwa sprawdzone snippety do functions.php aktywnego motywu lub Code Snippets.

Całkowite wyłączenie XML-RPC (WP 3.5+):

1
// Отключить XML-RPC полностью
2
add_filter('xmlrpc_enabled', '__return_false');

Jedna linijka i WordPress przestaje przetwarzać jakiekolwiek żądania XML-RPC. Przy próbie dostępu do xmlrpc.php klient otrzyma odpowiedź z błędem: sam plik pozostaje na serwerze, ale jest funkcjonalnie martwy.

Wyczyszczenie nagłówków wp_head z linków RSD i WLW:

Nawet po wyłączeniu XML-RPC WordPress nadal wstawia w <head> dwie linijki, które ujawniają informacje o Pana/Pani witrynie:

1
// Убрать ссылки RSD и WLW Manifest из заголовков
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Hooki rsd_link i wlwmanifest_link dodają w <head> tagi <link rel="EditURI"> i <link rel="wlwmanifest">: są one potrzebne wyłącznie klientom XML-RPC i nie mają praktycznego zastosowania w 2026 roku. Usuwamy je.

⚠️ Ważne: zmiany w functions.php motywu przepadną przy aktualizacji. Proszę używać motywu potomnego lub wtyczki Code Snippets do trwałego przechowywania niestandardowego kodu.

Sposób 3: wtyczki bezpieczeństwa

Jeśli nie chce Pan/Pani zagłębiać się w kod, proszę zainstalować wtyczkę. Trzy sprawdzone opcje:

• Wordfence Security. Najpopularniejsza zapora WordPressa. Oprócz blokowania XML-RPC oferuje skaner złośliwego kodu, ochronę logowania i monitorowanie ruchu. W ustawieniach Wordfence → Login Security → proszę zaznaczyć „Disable XML-RPC authentication".

• Disable XML-RPC-API. Lekka wtyczka, która robi dokładnie jedno: podpina filtr xmlrpc_enabled i wyłącza endpoint. Żadnych dodatkowych ustawień: aktywuje Pan/Pani i zapomina.

• iThemes Security (Solid Security). Kompleksowa wtyczka z modułem WordPress Tweaks, gdzie XML-RPC wyłącza się jednym kliknięciem. Przy okazji zamyka inne wektory: zmianę prefiksu tabel, wyłączenie edytora plików z panelu administracyjnego, ochronę przed brute force.

Po aktywacji którejkolwiek z wtyczek proszę koniecznie sprawdzić, czy xmlrpc.php zwraca błąd, a nie powitanie.

Sposób 4: blokowanie na poziomie zapory (Cloudflare / Sucuri)

Najpotężniejszy poziom ochrony to zapora aplikacji webowej (WAF), która odrzuca złośliwe żądania, zanim dotrą one do Pana/Pani hostingu.

Cloudflare** WAF.** Proszę utworzyć niestandardową regułę: pole URI Path zawiera xmlrpc.php → akcja Block. Żądania są filtrowane na poziomie sieci Cloudflare (ponad 330 punktów obecności na świecie), serwer ich nawet nie widzi. W planie Free dostępnych jest 5 niestandardowych reguł: to wystarczy. Bonus: Cloudflare pokazuje statystyki zablokowanych żądań i na własne oczy zobaczy Pan/Pani skalę ataków.

Sucuri Website Firewall. Analogiczne podejście: reguła WAF na URI /xmlrpc.php. Sucuri oferuje również monitorowanie integralności plików i automatyczne czyszczenie ze złośliwego kodu.

Regułę zapory wygodnie jest łączyć z .htaccess lub programowym wyłączeniem: zapora odcina masowy spam, a lokalny blok to zapasowa linia obrony na wypadek, gdyby ruch z jakiegoś powodu ominął WAF.

Co zrobić, jeśli korzysta Pan/Pani z Jetpacka

Jetpack od Automattic wykorzystuje XML-RPC do komunikacji Pana/Pani witryny z serwerami WordPress.com. Jeśli całkowicie wyłączy Pan/Pani xmlrpc.php, Jetpack przestanie działać: statystyki, subskrypcje, CDN dla obrazów, moduł Related Posts i ochrona przed brute force przez Jetpack odpadną razem.

Rozwiązanie: nie blokować XML-RPC całkowicie, ale punktowo przepuszczać żądania z serwerów Jetpacka:

• Proszę pozostawić xmlrpc.php dostępnym (NIE blokować przez .htaccess i NIE podpinać filtra xmlrpc_enabled).

• Proszę skonfigurować Cloudflare WAF tak: zezwolić na żądania do xmlrpc.php TYLKO z zakresów IP Automattic (lista jest aktualizowana w dokumentacji Jetpacka), resztę blokować.

• Jako minimum proszę usunąć nagłówki RSD i WLW snippetem ze sposobu 2, aby niepotrzebnie nie ujawniać endpointu w <head>.

• Proszę zainstalować Wordfence i włączyć ochronę przed brute force konkretnie dla xmlrpc.php: nie blokuje ona legalnych żądań Jetpacka, ale odcina próby złamania haseł.

⁉️🤔 Często zadawane pytania

Czy można po prostu usunąć plik xmlrpc.php z serwera?

Można, ale to zła praktyka. Przy następnej aktualizacji WordPressa plik zostanie przywrócony i znów będzie Pan/Pani narażony na ataki. Lepiej zablokować dostęp przez .htaccess lub wyłączyć funkcjonalność filtrem w kodzie: efekt ten sam, ale aktualizacje jądra nie zepsują ochrony. Jeśli jednak usunął Pan/Pani plik, proszę koniecznie usunąć rsd_link z wp_head, w przeciwnym razie odwiedzający otrzymają błąd 404 przy przejściu przez link EditURI.

Czy wyłączenie XML-RPC zepsuje WooCommerce?

Nie. WooCommerce całkowicie przeszedł na WordPress REST API i nie zależy od XML-RPC. Sklep będzie nadal działał bez zmian. Jedynym wyjątkiem jest sytuacja, gdy korzysta Pan/Pani ze starego, niestandardowego rozwiązania opartego na XML-RPC, ale praktycznie już takich nie ma.

Co zrobić, jeśli dostawca hostingu sam blokuje xmlrpc.php?

Jeśli dostawca wyłączył już XML-RPC na poziomie serwera, nie musi Pan/Pani nic robić: endpoint jest niedostępny. Proszę sprawdzić: otworzyć xmlrpc.php, jeśli jest 403, ochrona działa. Jedyne, co warto dodać, to usunięcie nagłówków RSD i WLW przez functions.php, ponieważ dostawca ich nie rusza.

Czy trzeba wyłączać XML-RPC, jeśli korzystam z hostingu WordPress zarządzanego?

Większość hostingów zarządzanych (Kinsta, WP Engine, SiteGround) blokuje lub mocno ogranicza xmlrpc.php na poziomie platformy. Proszę sprawdzić, czy endpoint jest otwarty przez przeglądarkę. Jeśli jest zablokowany, dodatkowe działania nie są potrzebne. Jeśli jest otwarty, proszę dodać regułę .htaccess: hostingi zarządzane jej nie nadpisują.

Jak sprawdzić, czy witryna jest atakowana przez xmlrpc.php właśnie teraz?

Trzy oznaki: gwałtowny skok obciążenia serwera przy niezmienionym ruchu, setki identycznych żądań POST do xmlrpc.php w logach dostępu oraz błędy przekroczenia limitów pamięci/procesora od dostawcy hostingu. Proszę włączyć monitorowanie (Wordfence → Live Traffic lub Cloudflare → Security Events): zobaczy Pan/Pani źródło i skalę ataku w czasie rzeczywistym.

Czy warto wyłączać xmlrpc.php w 2026 roku

Krótka odpowiedź: tak, jeśli nie korzysta Pan/Pani z Jetpacka i nie publikuje postów przez aplikację mobilną WordPressa.

XML-RPC to dziedzictwo ery WordPressa 1.5. REST API dawno zajął jego miejsce, a sam xmlrpc.php zamienił się w otwarte drzwi dla ataków brute force i DDoS. Zamknięcie ich to kwestia pięciu minut. Proszę wybrać sposób odpowiedni do swojej sytuacji:

• Nie chce Pan/Pani dotykać kodu: proszę zainstalować Disable XML-RPC-API, dwa kliknięcia.
• Ma Pan/Pani dostęp do plików serwera: proszę dodać regułę w .htaccess, poziom serwera jest bardziej niezawodny.
• Lubi Pan/Pani porządek w kodzie: proszę wrzucić filtr xmlrpc_enabled i usunąć nagłówki dwoma snippetami w functions.php.
• Chce Pan/Pani maksymalnej ochrony: proszę skonfigurować regułę WAF w Cloudflare i połączyć ją z lokalnym blokiem.

Po zablokowaniu proszę koniecznie sprawdzić, czy xmlrpc.php zwraca 403 Forbidden, i monitorować logi przynajmniej przez tydzień: zdziwi się Pan/Pani, ile śmieciowego ruchu zniknęło. A przy okazji proszę zasubskrybować aktualizacje WordPressa: historia pokazuje, że stare protokoły umierają powoli i nowe podatności w XML-RPC mogą wypłynąć nawet po 2026 roku.