Jak sprawdzić xmlrpc w WordPress?

Status XML-RPC w WordPressie sprawdzisz bez logowania do panelu. Najprościej użyć zewnętrznego testera, na przykład WordPress XML-RPC Validation Service, albo wysłać żądanie z terminala za pomocą polecenia curl. Jeśli nie korzystasz z aplikacji mobilnej, Jetpacka ani starszych integracji, zwykle możesz bezpiecznie zablokować plik xmlrpc.php.

Jak sprawdzić, czy XML-RPC jest aktywny?

Plik xmlrpc.php znajduje się w głównym katalogu WordPressa i umożliwia zewnętrznym aplikacjom wykonywanie wybranych operacji na stronie. Sam plik nie oznacza włamania, ale publicznie dostępny punkt końcowy może być wykorzystywany przez automatyczne skrypty.

Do szybkiej weryfikacji możesz użyć jednej z tych metod:

Tester online – otwórz WordPress XML-RPC Validation Service, wpisz pełny adres strony i wybierz przycisk „Check”. Zielony znacznik oznacza dostępny XML-RPC, a czerwony krzyżyk zwykle wskazuje na blokadę.
Terminal i curl – wyślij żądanie do adresu https://twojadomena.pl/xmlrpc.php i sprawdź kod odpowiedzi.
Logi serwera – wyszukaj żądania zawierające POST /xmlrpc.php. Ich obecność pokazuje, że ktoś próbuje komunikować się z tym punktem końcowym.

Przykładowe polecenie dla terminala wygląda tak:

curl -i -X POST https://twojadomena.pl/xmlrpc.php

Odpowiedź 200 może oznaczać, że punkt końcowy przyjmuje żądania. Kody 403 Forbidden lub 405 Method Not Allowed często wskazują na ograniczenie dostępu, ale wynik zależy od konfiguracji serwera i treści żądania. Dlatego po zmianie konfiguracji najlepiej porównać wynik z testem online i logami.

Metoda	Co sprawdza?	Kiedy jej użyć?
Tester online	Publiczną dostępność `xmlrpc.php`	Gdy potrzebujesz szybkiego wyniku bez dostępu do serwera
`curl`	Kod HTTP i odpowiedź punktu końcowego	Gdy masz dostęp do terminala lub SSH
Logi serwera	Rzeczywisty ruch i próby połączeń	Gdy chcesz sprawdzić aktywność po wdrożeniu blokady

Dlaczego XML-RPC może być ryzykowny?

XML-RPC pozwala zewnętrznym aplikacjom zdalnie publikować treści, edytować wpisy oraz wykonywać inne operacje wymagające uwierzytelnienia. Korzystają z niego między innymi aplikacja mobilna WordPressa, Jetpack, starsze narzędzia do publikowania oraz mechanizmy pingbacków i trackbacków.

Problem polega na tym, że jeden punkt końcowy może przyjmować wiele prób uwierzytelnienia w ramach żądań XML-RPC. To ułatwia automatyzowanie ataków typu Brute Force. Duża liczba żądań może też zwiększać obciążenie serwera, generować spam pingbackowy i być elementem ataku DDoS.

Blokada ma zwykle sens, gdy strona jest wizytówką, blogiem lub sklepem, a żadna zewnętrzna usługa nie potrzebuje XML-RPC. Zachowanie funkcji rozważ, jeśli:

publikujesz treści z aplikacji mobilnej WordPressa,
korzystasz z Jetpacka lub integracji WordPress.com,
używasz starszego edytora albo narzędzia wymagającego XML-RPC,
Twoja firma hostingowa lub konkretna integracja wyraźnie wymaga tego protokołu.

Jeżeli nie wiesz, że potrzebujesz XML-RPC, prawdopodobnie nie jest Ci potrzebny. Część nowoczesnych integracji może korzystać z REST API, ale przed blokadą sprawdź wymagania konkretnej usługi.

Jak zablokować XML-RPC w WordPressie?

Przed edycją plików wykonaj kopię zapasową strony i pliku, który zmieniasz. Błędna składnia w .htaccess może spowodować błąd serwera i czasową niedostępność witryny. Jeśli nie masz dostępu do FTP, SFTP, SSH lub menedżera plików hostingu, poproś administratora serwera o wdrożenie blokady.

Metoda	Trudność	Zastosowanie
`.htaccess`	Średnia	Blokada na serwerze Apache, przed obsługą żądania przez WordPress
`functions.php`	Średnia	Wyłączenie funkcji WordPressa za pomocą filtra PHP

Blokada przez .htaccess na serwerze Apache

Ta metoda odrzuca żądania do pliku na poziomie serwera. Otwórz plik .htaccess w katalogu instalacji WordPressa i dodaj regułę przed standardowym blokiem reguł WordPressa:

<Files "xmlrpc.php">
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order Allow,Deny
        Deny from all
    </IfModule>
</Files>

Następnie wykonaj kolejno:

Utwórz kopię pliku – pobierz oryginalny .htaccess na komputer lub zapisz jego kopię w menedżerze plików.
Otwórz właściwy katalog – upewnij się, że edytujesz plik należący do tej instalacji WordPressa.
Dodaj regułę blokującą – nie usuwaj istniejących reguł przekierowań ani sekcji WordPressa.
Zapisz plik i przetestuj stronę – sprawdź stronę główną, panel administracyjny oraz formularze.
Uruchom ponownie test XML-RPC – oczekuj informacji o blokadzie lub odpowiedzi serwera wskazującej na odmowę dostępu.

Plik .htaccess działa na serwerze Apache. Nginx nie obsługuje tego pliku, więc w jego przypadku blokadę trzeba dodać w konfiguracji serwera, na przykład jako regułę zwracającą kod 403 dla ścieżki /xmlrpc.php.

Wyłączenie funkcji przez functions.php

Drugą metodą jest użycie filtra WordPressa. Najlepiej dodać go w motywie potomnym, ponieważ aktualizacja głównego motywu może nadpisać zmiany. Kod umieść w pliku /wp-content/themes/nazwa-motywu-potomnego/functions.php:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Jeśli plik functions.php zawiera już otwierający znacznik <?php, nie dodawaj go ponownie. Po zapisaniu zmian:

Sprawdź składnię pliku – dodatkowy znak lub brak nawiasu może wywołać błąd PHP.
Otwórz stronę i panel WordPressa – upewnij się, że nie pojawił się błąd krytyczny.
Przetestuj integracje – sprawdź publikowanie z aplikacji mobilnej, Jetpacka, webhooków i innych używanych usług.
Zweryfikuj XML-RPC z zewnątrz – ponownie użyj testera online lub polecenia curl.

Jeśli nie chcesz edytować kodu, możesz użyć zaufanej wtyczki do zarządzania fragmentami kodu. Przed jej instalacją sprawdź kompatybilność z wersją WordPressa i wykonaj kopię zapasową.

Jak potwierdzić, że blokada działa?

Po wdrożeniu zmian nie kończ na zapisaniu pliku. Sprawdź zarówno dostęp do XML-RPC, jak i działanie funkcji strony.

Przejdź przez tę krótką listę kontrolną:

Tester online pokazuje, że XML-RPC jest zablokowany.
Polecenie curl zwraca odpowiedź odmowną, najczęściej 403 lub inną zgodną z konfiguracją serwera.
Strona główna, panel administracyjny i logowanie działają poprawnie.
Nie pojawiły się błędy PHP ani błędy serwera po edycji plików.
Jetpack, aplikacja mobilna i inne integracje działają albo zostały świadomie wyłączone.
Logi nie pokazują skutecznych żądań do xmlrpc.php po wdrożeniu blokady.

Jeśli Jetpack lub aplikacja mobilna przestały działać, usuń blokadę, przywróć kopię zapasową albo skonfiguruj ograniczony dostęp zgodnie z dokumentacją używanej usługi. Nie zostawiaj pełnej blokady bez sprawdzenia, czy nie odcina ona funkcji potrzebnej w codziennej pracy.

Dla większości stron bez zdalnych integracji blokada xmlrpc.php zmniejsza powierzchnię ataku i ogranicza niepotrzebny ruch. Najpierw potwierdź, że nie używasz tej funkcji, wykonaj kopię zapasową, zastosuj jedną metodę blokowania i sprawdź efekt z zewnątrz.