XML-RPC in WordPress deaktivieren oder einschränken: Webserver-Sperre, Filter und Pingbacks

Die Datei xmlrpc.php ist eine der ältesten Schnittstellen von WordPress. Sie stammt aus einer Zeit, in der Blog-Programme auf dem Desktop Beiträge per Fernzugriff veröffentlichten, und ist bis heute in jeder Installation aktiv. Für die meisten Unternehmenswebsites erfüllt sie keine Aufgabe mehr, zieht aber automatisierte Anmeldeversuche und Pingback-Missbrauch an. Diese Anleitung zeigt, was XML-RPC in WordPress 7.1 tatsächlich tut, welche Abschaltwege es gibt und warum der bekannte Einzeiler mit xmlrpc_enabled weniger abschaltet, als viele annehmen. Alle Wege wurden im Labor mit echten XML-RPC-Anfragen geprüft.

Voraussetzungen

• WordPress: getestet mit WordPress 7.1.2. Die verwendeten Filter existieren seit WordPress 3.5.
• PHP: im Test PHP 8.4, jede von WordPress unterstützte Version funktioniert.
• Webserver: Apache 2.4 mit erlaubter .htaccess oder Zugriff auf die nginx-Konfiguration. Bei Webhosting ohne eigene Serverkonfiguration genügt der Weg über das Must-Use-Plugin.
• Zugriff: Backend mit der Rolle Administrator sowie Dateizugriff per SFTP, FTP oder SSH. Für die Tests auf der Kommandozeile brauchen Sie curl.
• Backup: eine aktuelle Sicherung, mindestens von .htaccess und wp-content. Ein Fehler in der .htaccess kann die gesamte Website mit „500 Internal Server Error“ stoppen.

Schritt 1: Verstehen, was XML-RPC tut und wer es nutzt

Über xmlrpc.php nimmt WordPress Anfragen im XML-Format per POST entgegen. Im Test meldete die Methode system.listMethods 80 verfügbare Methoden, darunter Funktionen zum Anlegen von Beiträgen, zum Hochladen von Medien und die Pingback-Methoden. Zwei Eigenschaften machen die Schnittstelle für Angreifer interessant:

• Anmeldeversuche: Jede Methode mit Anmeldung prüft Benutzername und Passwort. Über system.multicall lassen sich mehrere Aufrufe in einer einzigen HTTP-Anfrage bündeln. Im Test prüfte eine Anfrage zwei Passwörter hintereinander und lieferte zweimal „Der Benutzername oder das Passwort ist falsch.“. Schutzmechanismen, die HTTP-Anfragen zählen, sehen dabei nur einen Versuch.
• Pingbacks: Die Methode pingback.ping veranlasst WordPress, eine fremde Adresse abzurufen. Das lässt sich missbrauchen, um Last auf Dritte zu lenken, und funktioniert ohne Anmeldung.

Klären Sie vor dem Abschalten, ob etwas die Schnittstelle legitim nutzt. Kandidaten sind ältere Desktop-Blogprogramme, Plugins oder externe Dienste, deren Dokumentation XML-RPC nennt. Neuere Anwendungen nutzen meist die REST-API. Der sicherste Hinweis sind die Zugriffsprotokolle des Webservers:

grep "xmlrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Der Pfad hängt von Distribution und Hoster ab, bei nginx lautet er oft /var/log/nginx/access.log. Viele Zugriffe von wechselnden, unbekannten Adressen sprechen für Angriffe, regelmäßige Zugriffe von einer bekannten Adresse für einen echten Dienst.

Verifizieren: Sie wissen, ob ein Dienst XML-RPC braucht, und haben gegebenenfalls dessen IP-Adresse notiert.

Schritt 2: Ausgangszustand testen

Damit Sie später belegen können, dass eine Sperre wirkt, testen Sie vorher. Ersetzen Sie www.example.de durch Ihre Adresse:

curl -s -i https://www.example.de/xmlrpc.php | head -1
curl -s -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' https://www.example.de/xmlrpc.php | grep -c "<string>"

Im Test lieferte der erste Befehl HTTP/1.1 405 Method Not Allowed mit dem Text „XML-RPC server accepts POST requests only.“. Das ist normal und bedeutet nicht, dass XML-RPC abgeschaltet ist: Die Schnittstelle antwortet nur nicht auf GET. Der zweite Befehl zählt die angebotenen Methoden, im Test 80.

Zusätzlich prüfen Sie, ob WordPress die Pingback-Adresse ankündigt. Bei einzelnen Beiträgen, die Pingbacks erlauben, sendet WordPress den HTTP-Header X-Pingback:

curl -s -I https://www.example.de/ein-beitrag/ | grep -i x-pingback

Verifizieren: Sie haben die Anzahl der Methoden und das Vorhandensein des X-Pingback-Headers notiert.

Schritt 3: XML-RPC auf dem Webserver sperren

Wenn kein Dienst XML-RPC braucht, sperren Sie die Datei vor WordPress. Das ist der gründlichste Weg: Anfragen erreichen PHP gar nicht erst, und die Website verbraucht für Angriffe keine Rechenzeit. Bei Apache ergänzen Sie die .htaccess im WordPress-Verzeichnis außerhalb des Blocks # BEGIN WordPress bis # END WordPress, denn diesen Block schreibt WordPress bei Änderungen der Permalinks neu:

# XML-RPC sperren
<Files "xmlrpc.php">
	Require all denied
</Files>

Im Test antwortete xmlrpc.php danach mit Status 403, die übrige Website lief unverändert. Bei nginx gehört die Regel in den server-Block Ihrer Website:

location = /xmlrpc.php {
    deny all;
}

Laden Sie nginx danach mit sudo nginx -t && sudo systemctl reload nginx neu. Die nginx-Variante wurde im Labor nicht getestet, die Direktive deny ist im Modul ngx_http_access_module dokumentiert. Einige Hoster bieten in ihrer Verwaltungsoberfläche eine eigene Option, XML-RPC zu sperren. Sie bewirkt dasselbe.

Verifizieren: curl -s -o /dev/null -w "%{http_code}\n" -d "x" https://www.example.de/xmlrpc.php gibt 403 aus, und die Startseite lädt normal.

Schritt 4: Zugriff auf bekannte Adressen beschränken

Nutzt ein Dienst XML-RPC von einer festen IP-Adresse aus, erlauben Sie nur diese. Bei Apache ersetzen Sie Require all denied durch eine Liste erlaubter Adressen:

<Files "xmlrpc.php">
	Require ip 203.0.113.10
</Files>

Die Adresse 203.0.113.10 ist ein Platzhalter aus dem Dokumentationsbereich, tragen Sie die echte Adresse des Dienstes ein. Mehrere Adressen trennen Sie durch Leerzeichen. Im Test erhielt die erlaubte Adresse Status 200. Steht die Website hinter einem Proxy oder CDN, sieht Apache nur dessen Adresse. Dann greift die Regel nicht wie gedacht, und Sie müssen die echte Client-Adresse zuerst über das Modul mod_remoteip herstellen.

Verifizieren: Von der erlaubten Adresse funktioniert der Dienst weiter, von jeder anderen Adresse antwortet xmlrpc.php mit 403.

Schritt 5: In WordPress selbst einschränken

Ohne Zugriff auf die Serverkonfiguration bleibt der Weg über Filter in einem Must-Use-Plugin. Legen Sie die Datei wp-content/mu-plugins/xmlrpc.php an, wie in Update-Benachrichtigungen per E-Mail steuern beschrieben. Viel zitiert wird dieser Einzeiler:

<?php
/**
 * Plugin Name: XML-RPC einschränken
 */
defined( 'ABSPATH' ) || exit;

add_filter( 'xmlrpc_enabled', '__return_false' );

Laut Dokumentation im Quelltext steuert xmlrpc_enabled entgegen seinem Namen nur Methoden mit Anmeldung. Der Test bestätigt das: wp.getUsersBlogs antwortete danach mit Fehlercode 405 und „Die XML-RPC-Dienste sind auf dieser Website deaktiviert.“, auch innerhalb von system.multicall. Die Methodenliste zeigte aber weiterhin 80 Einträge, und pingback.ping wurde weiter angenommen. Für Pingbacks ergänzen Sie deshalb den Filter xmlrpc_methods und entfernen den Header X-Pingback:

add_filter( 'xmlrpc_methods', function ( $methods ) {
	unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
	return $methods;
} );

add_filter( 'wp_headers', function ( $headers ) {
	unset( $headers['X-Pingback'] );
	return $headers;
} );

Im Test antwortete pingback.ping danach mit „requested method pingback.ping does not exist.“, die Liste zählte 78 Methoden, und der Header fehlte. system.multicall lässt sich auf diesem Weg nicht entfernen: Die Methode gehört zur XML-RPC-Bibliothek und war im Test auch nach unset weiter aufrufbar. Zusammen mit xmlrpc_enabled laufen darüber aber keine Anmeldeversuche mehr.

Der Nachteil dieses Wegs: Jede Anfrage startet weiterhin WordPress und PHP. Bei vielen Angriffen kostet das Rechenzeit, die eine Sperre im Webserver spart.

Verifizieren: php -l wp-content/mu-plugins/xmlrpc.php meldet keine Syntaxfehler, und ein Test mit wp.getUsersBlogs liefert Fehlercode 405 statt 403.

Schritt 6: Pingbacks in den Einstellungen abschalten

Unabhängig vom gewählten Weg sollten Sie Pingbacks im Backend abschalten, wenn Sie sie nicht nutzen. Öffnen Sie Einstellungen > Diskussion und entfernen Sie unter „Standardeinstellungen für Beiträge“ die Haken bei „Alle Blogs, die im Beitrag verlinkt sind, versuchen zu benachrichtigen“ und „Link-Benachrichtigungen von anderen Blogs (Pingbacks und Trackbacks) zu neuen Beiträgen erlauben“. Per WP-CLI setzen Sie dieselben Optionen so:

wp option update default_ping_status closed
wp option update default_pingback_flag 0

Die Einstellung gilt nur für neue Beiträge. Bestehende Beiträge behalten ihren Status, den Sie in der Beitragsübersicht per Mehrfachbearbeitung ändern können.

XML-RPC ist ein Baustein unter vielen. Updates, Backups und die Überwachung der Firewall laufen dauerhaft weiter. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Einrichtung und Wartung der Firewall, Updates mit Kompatibilitätsprüfung und wöchentliche externe Backups.

Verifizieren: wp option get default_ping_status gibt closed aus, wp option get default_pingback_flag gibt 0 aus.

Typische Fehler

• „XML-RPC server accepts POST requests only.“ gilt als Beweis, dass XML-RPC aus ist: Falsch. Diese Antwort mit Status 405 kommt bei jedem Aufruf im Browser. Testen Sie immer per POST, siehe Schritt 2.
• Nach dem Filter xmlrpc_enabled laufen weiter Pingback-Anfragen ein: Erwartetes Verhalten, der Filter betrifft nur Methoden mit Anmeldung. Ergänzen Sie xmlrpc_methods oder sperren Sie im Webserver.
• „500 Internal Server Error“ nach Änderung der .htaccess: Tippfehler oder ein Modul fehlt. Stellen Sie die Sicherung der .htaccess wieder her und prüfen Sie das Fehlerprotokoll des Webservers.
• Die Regel steht in der .htaccess, ist nach einiger Zeit aber verschwunden: Sie stand innerhalb von # BEGIN WordPress und # END WordPress, den WordPress neu schreibt. Setzen Sie sie außerhalb dieses Blocks.
• Ein Dienst funktioniert nach der Sperre nicht mehr: Er nutzte XML-RPC. Erlauben Sie seine IP-Adresse wie in Schritt 4 oder stellen Sie ihn auf die REST-API mit Anwendungspasswörtern um, falls der Anbieter das unterstützt.

Häufige Fragen

Ersetzt die Sperre von XML-RPC einen Schutz der Anmeldeseite?

Nein. Angriffe auf wp-login.php laufen unabhängig davon. Starke Passwörter, Zwei-Faktor-Anmeldung und eine Begrenzung der Anmeldeversuche bleiben nötig. Auf eigenen Servern hilft zusätzlich Fail2Ban, wie in VPS absichern und härten beschrieben.

Brauche ich ein Plugin, um XML-RPC abzuschalten?

Nein. Die gezeigten Regeln kommen ohne Plugin aus. Ein Plugin bietet nur eine Oberfläche für dieselben Filter und bringt zusätzlichen Code, den Sie aktuell halten müssen.

Beeinträchtigt die Sperre die REST-API oder den Block-Editor?

Nein. Block-Editor und REST-API nutzen /wp-json/ und sind von der Sperre von xmlrpc.php nicht betroffen. Im Test lieferte /wp-json/ bei gesperrter xmlrpc.php weiter Status 200.

Testumfang

Wir haben auf einer Testinstanz mit WordPress 7.1.2 echte XML-RPC-Anfragen per curl geschickt, darunter mehrere Anmeldeversuche in einer einzigen Anfrage. Nicht geprüft haben wir die nginx-Regel und den Betrieb hinter Proxy oder CDN.

Da auch konkrete Dienste, die XML-RPC nutzen, ungetestet blieben, probieren Sie die Änderungen bitte zuerst auf einer Kopie Ihrer Seite aus.

Fazit

Braucht kein Dienst XML-RPC, sperren Sie xmlrpc.php im Webserver. Ist das nicht möglich, kombinieren Sie xmlrpc_enabled mit dem Entfernen der Pingback-Methoden, denn der Einzeiler allein lässt Pingbacks offen. Pingbacks schalten Sie in jedem Fall in den Diskussionseinstellungen ab. Wer Firewall und Updates dauerhaft betreuen lassen möchte, findet das bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Update-Benachrichtigungen per E-Mail steuern (mit Must-Use-Plugin)
• VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban
• WordPress nach Datenverlust wiederherstellen
• Code-Referenz: xmlrpc_enabled
• Code-Referenz: xmlrpc_methods
• Apache-Dokumentation: mod_authz_core (Require)
• nginx-Dokumentation: ngx_http_access_module