--- title: "XML-RPC in WordPress deaktivieren oder einschränken: Webserver-Sperre, Filter und Pingbacks" date: 2026-09-30T21:13:28+02:00 modified: 2026-11-08T22:09:27+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-xml-rpc-deaktivieren-einschraenken keywords: - WordPress - Sicherheit - XML-RPC - Apache - Brute-Force reading_time: 8 --- # 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 mit echten XML-RPC-Anfragen geprüft. **Kurzfassung:** Prüfen Sie zuerst, ob ein Dienst Ihrer Website XML-RPC nutzt. Wenn nicht, sperren Sie `xmlrpc.php` auf Ebene des Webservers, das ist der gründlichste Weg. Der Filter `xmlrpc_enabled` schaltet nur Methoden mit Anmeldung ab, Pingbacks laufen weiter. Brauchen Sie XML-RPC noch, entfernen Sie gezielt Pingback-Methoden, beschränken Sie den Zugriff auf bekannte IP-Adressen und schalten Sie Pingbacks in den Diskussionseinstellungen ab. ## Voraussetzungen - [ ] **WordPress:** eine aktuelle Version. Die verwendeten Filter existieren seit WordPress 3.5. - [ ] **PHP:** 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. Mehrere Fehlermeldungen belegen dabei nicht mehrere Passwortprüfungen: Nach dem ersten fehlgeschlagenen Login weist WordPress weitere Anmeldeaufrufe derselben Anfrage ohne erneute Prüfung zurück. Die Methode kann dennoch mehrere andere Aufrufe bündeln. - **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: ```bash $ 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. > **Prüfen:** 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: ```bash $ curl -s -i https://www.example.de/xmlrpc.php | head -1 $ curl -s -d 'system.listMethods' https://www.example.de/xmlrpc.php | grep -o "" | wc -l ``` 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`: ```bash $ curl -s -I https://www.example.de/ein-beitrag/ | grep -i x-pingback ``` > **Prüfen:** 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: ```apache # XML-RPC sperren Require all denied ``` 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: ```nginx location = /xmlrpc.php { deny all; } ``` Laden Sie nginx danach mit `sudo nginx -t && sudo systemctl reload nginx` neu. 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. > **Prüfen:** `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: ```apache Require ip 203.0.113.10 ``` 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. > **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-update-benachrichtigungen-e-mail-steuern) beschrieben. Viel zitiert wird dieser Einzeiler: Datei: `wp-content/mu-plugins/xmlrpc.php` ```php **Prüfen:** `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: ```bash $ 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=28) übernimmt Einrichtung und Wartung der Firewall, Updates mit Kompatibilitätsprüfung und wöchentliche externe Backups. > **Prüfen:** `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](https://s-edv.com/anleitungen/vps-absichern-haerten-ufw-ssh-keys-fail2ban) beschrieben. Die Grundlagen zu Firewall und Fail2Ban auf Linux-Servern erklärt [Linux-Server absichern: UFW-Firewall und Fail2ban](https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban). ### 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`. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=28). ## Weiterführende Anleitungen und Quellen - [Update-Benachrichtigungen per E-Mail steuern (mit Must-Use-Plugin)](https://s-edv.com/anleitungen/wordpress-update-benachrichtigungen-e-mail-steuern) - [VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban](https://s-edv.com/anleitungen/vps-absichern-haerten-ufw-ssh-keys-fail2ban) - [WordPress nach Datenverlust wiederherstellen](https://s-edv.com/anleitungen/wordpress-wiederherstellen-datenverlust-backup-restore) - [Code-Referenz: xmlrpc_enabled](https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/) - [Code-Referenz: xmlrpc_methods](https://developer.wordpress.org/reference/hooks/xmlrpc_methods/) - [Apache-Dokumentation: mod_authz_core (Require)](https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html) - [nginx-Dokumentation: ngx_http_access_module](https://nginx.org/en/docs/http/ngx_http_access_module.html)