xmlrpc.php w WordPress, wyłączyć czy nie?

Czym jest xmlrpc.php w WordPress?

Plik xmlrpc.php to interfejs API oparty na protokole XML-RPC, obecny w WordPressie od wielu lat. Jego zadanie to umożliwienie zdalnej komunikacji ze stroną bez logowania przez przeglądarkę. Historycznie korzystały z niego:

• Oficjalna aplikacja mobilna WordPress (iOS i Android), do publikowania postów i zarządzania treścią,
• Jetpack, wtyczka Automattic, która przez XML-RPC synchronizuje dane z serwerami jetpack.com,
• Narzędzia do zdalnego blogowania takie jak Windows Live Writer czy MarsEdit,
• Systemy pingback, automatyczne powiadamianie innych blogów o linkach.

Dziś aplikacja mobilna WordPress i Jetpack w nowszych wersjach coraz częściej używają REST API, jednak xmlrpc.php nadal pozostaje aktywny w większości instalacji WordPressa, i właśnie tam czyhają problemy.

Zagrożenia związane z xmlrpc.php WordPress

Problem nie leży w samej technologii, ale w tym, jak łatwo można ją wykorzystać do ataku.

Amplifikacja brute-force przez system.multicall

XML-RPC obsługuje metodę system.multicall, która pozwala wysłać wiele wywołań API w jednym żądaniu HTTP. Atakujący może w jednym zapytaniu sprawdzić kilkaset kombinacji login/hasło, efektywność ataku rośnie kilkusetkrotnie w porównaniu ze zwykłym formularzem logowania. Serwer przetwarza każde wywołanie, więc obciążenie rośnie niezależnie od tego, czy blokada IP jest aktywna.

Pingback DDoS

Metoda pingback.ping pozwala wymusić na Twoim WordPressie wysłanie żądania HTTP pod dowolny adres URL. Atakujący mogą wykorzystać setki lub tysiące podatnych stron WordPress jako przekaźniki, każda z nich bombarduje cel żądaniami pingback. Twoja strona staje się mimowolnym uczestnikiem ataku DDoS, a Ty możesz trafić na czarne listy IP.

Jak sprawdzić, czy potrzebujesz xmlrpc.php?

Zanim cokolwiek zablokujesz, sprawdź dwie rzeczy:

1. Logi dostępu serwera, w panelu hostingu (home.pl, cyber_Folks, LH.pl) znajdź access.log i sprawdź, czy widać żądania POST do /xmlrpc.php z adresów IP serwerów Automattic (Jetpack) lub własnych urządzeń.
2. Używane wtyczki i narzędzia, sprawdź, czy masz aktywny Jetpack, aplikację mobilną WordPress lub narzędzie do zdalnego blogowania. Jeśli nie, możesz śmiało blokować.

W zdecydowanej większości małych stron firmowych i blogów xmlrpc.php jest kompletnie zbędny i można go zablokować bez żadnych konsekwencji.

Metody wyłączenia xmlrpc.php WordPress

Masz kilka sposobów, od najprostszych po najbardziej skuteczne. Polecam zacząć od wtyczki lub filtra, a jeśli prowadzisz stronę na serwerze, który kontrolujesz, dodać blokadę na poziomie serwera WWW.

1. Wtyczka (najszybciej dla każdego)

Zainstaluj wtyczkę Disable XML-RPC lub Disable XML-RPC Pingback z repozytorium WordPress.org. Aktywujesz, nie konfigurujesz, gotowe. Ta metoda blokuje dostęp przez WordPress, ale żądania nadal docierają do serwera i zużywają zasoby.

2. Filtr w functions.php lub wtyczce mu-plugins

Możesz dodać filtr do pliku functions.php motywu potomnego lub do pliku w katalogu wp-content/mu-plugins/:

add_filter( 'xmlrpc_enabled', '__return_false' );

To wyłącza obsługę XML-RPC po stronie WordPressa. Nadal nie blokuje żądań przed dotarciem do PHP, do tego służą metody poniżej.

3. Blokada w .htaccess (serwery Apache)

Jeśli Twój hosting działa na Apache (większość hostingów współdzielonych), dopisz do pliku .htaccess w głównym katalogu:

# Blokada xmlrpc.php
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Serwer zwróci błąd 403, zanim żądanie trafi do PHP. Minimalne zużycie zasobów, maksymalna skuteczność.

4. Blokada w konfiguracji Nginx

Dla serwerów Nginx (VPS, serwery dedykowane) dodaj do bloku server {}:

location = /xmlrpc.php {
  deny all;
  return 403;
}

5. Reguła w Cloudflare WAF

Jeśli Twoja strona jest chroniona przez Cloudflare, możesz stworzyć regułę zapory (WAF Custom Rule), która blokuje żądania do /xmlrpc.php jeszcze zanim dotrą do serwera. To najefektywniejsze rozwiązanie, ataki są zatrzymywane na poziomie CDN, bez żadnego obciążenia hostingu. Więcej o konfiguracji Cloudflare dla WordPress opisuję w usłudze Ochrona Cloudflare dla WordPress.

Kiedy zostawić xmlrpc.php włączony?

Są sytuacje, w których xmlrpc.php jest potrzebny:

• Aktywnie używasz oficjalnej aplikacji mobilnej WordPress i nowsza wersja nie przeszła jeszcze na REST API,
• Korzystasz z Jetpacka w starszej wersji lub z funkcji, które wymagają XML-RPC,
• Używasz narzędzia do zewnętrznego publikowania (MarsEdit, Windows Live Writer).

W takim przypadku zamiast blokować całkowicie, ogranicz dostęp do konkretnych adresów IP, np. tylko do serwerów Automattic lub własnego adresu biurowego. Kompleksową analizę słabych punktów Twojej strony oferuję w ramach audytu bezpieczeństwa WordPress.

Jeśli nie masz pewności co do konfiguracji lub chcesz zadbać o bezpieczeństwo strony kompleksowo, przeczytaj też jak zabezpieczyć WordPress w 2025 roku, zebrałem tam wszystkie kluczowe kroki w jednym miejscu.

Kiedy lepiej zadzwonić do specjalisty

Jeśli widzisz w logach tysiące żądań do xmlrpc.php, hosting wysyła Ci ostrzeżenia o przekroczeniu limitów CPU albo strona zwalnia bez wyraźnej przyczyny, to sygnał, że trwa aktywny atak lub już doszło do kompromitacji. Samodzielna blokada może nie wystarczyć, jeśli atakujący zdążył wgrać backdoora lub zebrać dane logowania. W takich przypadkach zadzwoń do mnie: 577 020 415, przeprowadzę audyt, usunę zagrożenie i skonfiguruję skuteczną ochronę na poziomie serwera i Cloudflare.