XML-RPC in WordPress: Was die Schnittstelle macht, warum sie ein Sicherheitsrisiko ist — und wie man sie abschaltet

Die Datei xmlrpc.php existiert in jeder WordPress-Installation. Sie liegt im Wurzelverzeichnis, direkt neben wp-login.php und wp-config.php. Die meisten Site-Betreiber wissen nicht, dass sie da ist — Angreifer schon. In WordPress-Wartungslogs taucht xmlrpc.php regelmäßig als Ziel automatisierter Angriffe auf, oft mit tausenden Anfragen pro Stunde. Was steckt dahinter, und warum sollte man die Schnittstelle in den meisten Fällen deaktivieren?

Was ist XML-RPC?

XML-RPC (Extensible Markup Language – Remote Procedure Call) ist ein Protokoll, das Programme über HTTP miteinander kommunizieren lässt. Die Idee stammt aus dem Jahr 1998 — lange vor REST-APIs, JSON und modernen Webstandards. Das Prinzip: Ein Client schickt eine XML-formatierte Anfrage an einen Server, der Server führt die gewünschte Aktion aus und antwortet ebenfalls in XML.

WordPress hat XML-RPC seit Version 3.5 (2012) standardmäßig aktiviert. Ursprünglich war die Schnittstelle dafür gedacht, WordPress aus externen Anwendungen heraus zu steuern: Blogbeiträge veröffentlichen, Kommentare moderieren, Medien hochladen — alles ohne das WordPress-Dashboard im Browser zu öffnen.

Was XML-RPC in WordPress konkret macht

Über die xmlrpc.php lassen sich rund 80 WordPress-Funktionen fernsteuern. Die wichtigsten Anwendungsfälle waren historisch:

• Desktop-Blogging-Tools — Programme wie Windows Live Writer oder MarsEdit konnten Beiträge direkt in WordPress veröffentlichen, ohne dass der Autor den Browser bemühen musste.
• Mobile Apps — die älteren WordPress-Apps für iOS und Android nutzten XML-RPC, bevor die REST-API eingeführt wurde.
• Pingbacks und Trackbacks — XML-RPC wickelte die Benachrichtigungen ab, wenn ein anderer Blog auf einen Beitrag verlinkte.
• Drittanbieter-Integrationen — IFTTT, Zapier und ähnliche Dienste nutzten die Schnittstelle zur Automatisierung.

Das Problem: All diese Anwendungsfälle werden seit WordPress 4.7 (2016) von der REST-API abgedeckt — moderner, sicherer und mit feingranularer Authentifizierung. Die XML-RPC-Schnittstelle ist damit funktional obsolet, bleibt aber aus Kompatibilitätsgründen aktiv.

Warum XML-RPC ein massives Sicherheitsproblem ist

Die Schnittstelle vereint mehrere Eigenschaften, die sie zum idealen Angriffsvektor machen:

1. Brute-Force-Angriffe — am Login vorbei

Wer wp-login.php mit Rate-Limiting, CAPTCHA oder Login-Lockdown absichert, vergisst oft, dass XML-RPC einen zweiten Login-Weg bietet. Die Methode wp.getUsersBlogs prüft Benutzername und Passwort — und zwar ohne jede Ratenbegrenzung. Ein Angreifer kann tausende Kombinationen pro Minute testen, ohne dass ein klassisches Brute-Force-Plugin Alarm schlägt.

Noch effizienter: die Methode system.multicall. Sie erlaubt es, hunderte Login-Versuche in einer einzigen HTTP-Anfrage zu bündeln. Statt 500 einzelne Requests zu senden (die ein WAF leicht erkennt), schickt der Angreifer einen einzigen POST-Request mit 500 Passwort-Kombinationen. Das umgeht Anfrage-basierte Rate-Limiter vollständig.

2. DDoS-Amplification über Pingbacks

Die Pingback-Funktion von XML-RPC lässt sich als DDoS-Verstärker missbrauchen. Das Prinzip: Ein Angreifer sendet massenweise Pingback-Anfragen an tausende WordPress-Sites und gibt als Ziel-URL die Domain des Opfers an. Jede WordPress-Installation schickt daraufhin eine HTTP-Anfrage an das Opfer — der Angreifer nutzt fremde Server als „Verstärker“. Die angegriffene Site sieht keine einzige Anfrage des Angreifers, sondern nur legitimene WordPress-Installationen, die sie aufrufen.

Dieses Szenario ist kein theoretisches Konstrukt. Der Sicherheitsanbieter Sucuri dokumentierte bereits 2014 eine Pingback-basierte DDoS-Attacke, bei der über 162.000 WordPress-Sites als unwissentliche Angreifer missbraucht wurden. Die Methode wird bis heute eingesetzt.

3. Informationsleck

Über XML-RPC lassen sich Informationen über die WordPress-Installation abfragen, die einem Angreifer die Vorbereitung erleichtern: WordPress-Version, installierte Methoden, gültige Benutzernamen. Jedes Detail reduziert den Aufwand für einen gezielten Angriff.

4. Keine moderne Authentifizierung

XML-RPC authentifiziert ausschließlich per Benutzername und Passwort — im Klartext, bei jedem einzelnen Request. Es gibt keine Token, keine OAuth-Flows, keine Zwei-Faktor-Unterstützung. Selbst wenn 2FA für wp-login.php aktiviert ist, lässt XML-RPC den Zugang ohne zweiten Faktor zu. Diese Lücke ist vielen Site-Betreibern nicht bewusst.

Wie man prüft, ob XML-RPC aktiv ist

Ein einfacher Test im Browser: Rufen Sie https://ihre-domain.de/xmlrpc.php auf. Wenn Sie die Meldung „XML-RPC server accepts POST requests only“ sehen, ist die Schnittstelle aktiv und erreichbar.

Alternativ per Terminal:

$ curl -s -o /dev/null -w "%{http_code}" https://ihre-domain.de/xmlrpc.php

Ein HTTP-Statuscode 405 oder 200 bestätigt, dass die Datei erreichbar ist. Ein 403 oder 404 bedeutet, dass der Zugriff bereits blockiert wird.

XML-RPC deaktivieren — drei Wege

In den meisten WordPress-Installationen wird XML-RPC nicht mehr benötigt. Die REST-API hat alle relevanten Anwendungsfälle übernommen. Die einzige Ausnahme: Wer noch ein älteres Plugin oder einen Dienst einsetzt, der explizit XML-RPC erfordert (z. B. die veraltete Jetpack-Anbindung über xmlrpc.php). Im Zweifel lässt sich das leicht testen — XML-RPC deaktivieren und prüfen, ob alle Funktionen weiterhin arbeiten.

Weg 1: Blockierung auf Server-Ebene (empfohlen)

Die sauberste Lösung: Den Zugriff auf xmlrpc.php direkt im Webserver blockieren, bevor WordPress überhaupt PHP ausführen muss. Das spart Serverressourcen und ist gegen Manipulation aus WordPress heraus immun.

Apache (.htaccess):

<Files xmlrpc.php>
  Require all denied
</Files>

Nginx:

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

Weg 2: WordPress-Filter

Wer keinen direkten Zugriff auf die Serverkonfiguration hat, kann XML-RPC über einen WordPress-Filter deaktivieren. In der functions.php des aktiven Themes oder — besser — in einem eigenen Mini-Plugin:

add_filter( 'xmlrpc_enabled', '__return_false' );

Wichtig: Dieser Filter deaktiviert die Authentifizierung, aber die Datei xmlrpc.php bleibt erreichbar — Pingback-Anfragen und system.multicall können weiterhin den Server belasten. Deshalb ist Weg 1 (Server-Blockierung) die bessere Lösung.

Weg 3: Sicherheits-Plugin

Plugins wie Wordfence, Solid Security (ehemals iThemes Security) oder All-In-One WP Security bieten eine Option zum Deaktivieren von XML-RPC. Das ist der einfachste Weg für Einsteiger — hat aber den Nachteil, dass die Blockierung nur innerhalb von WordPress greift und bei jedem Request trotzdem PHP gestartet wird.

Was man zusätzlich tun sollte

XML-RPC deaktivieren ist ein guter erster Schritt, aber kein Gesamtkonzept. Die Schnittstelle ist nur eines von mehreren Einfallstoren, die eine WordPress-Installation exponiert. Weitere Härtungsmaßnahmen, die in denselben Kontext gehören:

• REST-API einschränken — die REST-API ist mächtiger als XML-RPC. Nicht-authentifizierte Endpunkte wie /wp-json/wp/v2/users geben Benutzernamen preis. Zugriff einschränken, wo nicht benötigt.
• wp-login.php absichern — Rate-Limiting, 2FA, IP-Whitelist für Admins.
• HTTP-Header setzen — X-Content-Type-Options, X-Frame-Options, Content-Security-Policy.
• WordPress-Version verbergen — den meta generator-Tag und die readme.html entfernen.
• Updates zeitnah einspielen — die beste Härtung nützt nichts, wenn ein Plugin mit bekannter Schwachstelle monatelang ungeupdatet bleibt.

Fazit

XML-RPC ist ein Relikt aus einer Zeit, in der WordPress keine REST-API hatte. Die Schnittstelle hat ihren Zweck erfüllt, ist aber seit Jahren funktional überflüssig — und gleichzeitig eine der am häufigsten missbrauchten Angriffsflächen im WordPress-Ökosystem. Brute-Force-Angriffe über system.multicall, DDoS-Amplification über Pingbacks und die vollständige Umgehung von 2FA machen xmlrpc.php zu einem der ersten Punkte, die bei einer WordPress-Härtung adressiert werden sollten.

Unsere Empfehlung: Auf Server-Ebene blockieren, sofern kein konkreter Anwendungsfall die Schnittstelle erfordert. Das kostet fünf Minuten und schließt einen Angriffsvektor, der täglich automatisiert getestet wird.

Wir prüfen im Rahmen unserer WordPress-Wartung bei jeder betreuten Site, ob XML-RPC deaktiviert ist — und blockieren die Schnittstelle standardmäßig auf Server-Ebene. Wenn Sie unsicher sind, ob Ihre Site betroffen ist: Unsere kostenlose Erstanalyse gibt Auskunft.