xmlrpc.php in WordPress: prüfen, sperren oder drosseln

xmlrpc.php liegt im Hauptverzeichnis jeder WordPress-Installation. Dahinter steckt XML-RPC, eine Fernschnittstelle aus der Zeit vor der REST-API: Desktop-Programme und Apps konnten damit Beiträge anlegen, und Blogs schickten sich gegenseitig Pingbacks. Seit WordPress 3.5 vom Dezember 2012 gibt es dafür keinen Schalter mehr in den Einstellungen; die Schnittstelle ist immer an, und den alten Schalter ersetzt der Filter xmlrpc_enabled. Seit WordPress 4.7 vom Dezember 2016 macht die REST-API unter /wp-json/ dieselbe Arbeit, und der Block-Editor arbeitet nur noch damit. Für die meisten Websites ist xmlrpc.php deshalb ein Eingang, den niemand mehr benutzt, der aber offen steht.

Erreichbar heißt nicht gleich gefährdet, aber es heißt angreifbar. Jede Anmeldung über diese Datei läuft an der Anmeldeseite vorbei. Ein Captcha auf wp-login.php sieht sie nie. Ob ein Plugin, das Fehlversuche zählt, auch Anmeldungen über XML-RPC zählt, steht in dessen Beschreibung, nicht im Namen.

Was über xmlrpc.php geht#

Die Serverklasse wp_xmlrpc_server bietet die WordPress-Methoden (wp.getUsersBlogs, wp.newPost und so weiter), die älteren Blogger-, MetaWeblog- und MovableType-Schnittstellen und pingback.ping. Dazu kommen zwei Systemmethoden, die die darunterliegende Serverklasse selbst registriert: system.listMethods, das die Liste ausgibt, und system.multicall, das mehrere Aufrufe in einer Anfrage bündelt. Fast jede Methode nimmt Benutzername und Passwort als Parameter entgegen und prüft sie mit derselben Funktion wie die Anmeldeseite.

Zwei Angriffe hängen daran, beide gut dokumentiert:

Passwort-Raten mit system.multicall. Im Oktober 2015 beschrieb Sucuri, wie Angreifer hunderte Anmeldeversuche in eine einzige HTTP-Anfrage packten: ein Eintrag im Zugriffsprotokoll, hunderte Passwörter. WordPress 4.4 vom Dezember 2015 hat das gebremst (Ticket #34336): Scheitert in einer Anfrage die erste Anmeldung, scheitern alle weiteren in derselben Anfrage, ohne dass das Passwort noch geprüft wird; im Quelltext ist das die Eigenschaft auth_failed. Seitdem bleibt ein Versuch pro Anfrage. Anfragen sind billig, und die Datei antwortet jedem.

Pingback als Waffe. Ein Pingback bittet deine Seite, eine fremde Adresse abzurufen und nachzusehen, ob dort ein Link auf dich steht. Im März 2014 zählte Sucuri über 162.000 WordPress-Seiten, die auf diese Weise als Verstärker für einen Angriff auf eine fremde Website benutzt wurden, jede mit Anfragen an zufällige Adressen, damit kein Cache greift. Schon WordPress 3.5.1 vom Januar 2013 hatte eine Lücke geschlossen, über die Pingbacks zum Scannen fremder Server dienten. Übrig bleibt, dass jeder Pingback-Aufruf deinen Server eine fremde Adresse abrufen lässt. Dazu verrät WordPress die Schnittstelle selbst: Auf einzelnen Beiträgen, für die Pingbacks erlaubt sind, schickt es die Kopfzeile X-Pingback mit der Adresse der xmlrpc.php mit.

Meine Messung: 21 Tiroler WordPress-Seiten#

Am 03.10.2026 hatte ich 131 Websites Tiroler Betriebe und Tourismusverbände auf Kopfzeilen und CMS geprüft, 22 davon liefen auf WordPress (zwei Domains führten zur selben Seite, bleiben 21). Am 13.10.2026 habe ich bei diesen 21 die Datei xmlrpc.php einmal per GET abgerufen, mit eigener Kennung, ohne POST, ohne Anmeldeversuch, ohne Methodenliste. Nur der Antwortcode zählt, Namen nenne ich nicht.

Neun Seiten antworten mit dem Standardtext „XML-RPC server accepts POST requests only.“; die Schnittstelle ist erreichbar. Acht antworten mit 403, dort sperrt der Webserver, eine Firewall oder ein Plugin die Datei. Vier antworten mit 404. Ein 403 oder 404 ist das Ziel, wenn nichts auf der Seite die Schnittstelle braucht. Ob bei den neun erreichbaren die Anmeldemethoden eingeschaltet sind, habe ich nicht geprüft, dazu wäre ein POST nötig, und das ist kein passiver Test mehr.

Prüfen, ob du es brauchst#

Drei Minuten, in dieser Reihenfolge:

1. https://deine-domain.at/xmlrpc.php im Browser aufrufen. „XML-RPC server accepts POST requests only.“ heißt erreichbar. 403 oder 404 heißt gesperrt, dann bist du fertig, außer Punkt 2 sagt etwas anderes.
2. Jetpack? Jetpack schreibt in seiner Hilfe, dass es diese Datei braucht, um sich mit WordPress.com zu verbinden, und empfiehlt genau diesen Aufruf als Test. Einige Hoster sperren die Datei standardmäßig, laut Jetpack WP Engine für Umgebungen seit April 2022, Pantheon und Flywheel, und Jetpack läuft dort erst nach einer Ausnahme. Unter Werkzeuge → Website-Zustand zeigt Jetpack seine Verbindungsprobleme an.
3. WordPress-App oder Fernwartung? Die Apps für iOS und Android sprechen mit selbst gehosteten Seiten über XML-RPC, die WordPress-Dokumentation nennt mobile Apps neben Jetpack als typische Nutzer. Werkzeuge, die viele Installationen aus der Ferne pflegen, oft auch. Wer so etwas einsetzt, weiß es meist.

Wer ein Zugriffsprotokoll lesen kann, sieht außerdem, wer die Datei tatsächlich aufruft:

grep -c 'POST /xmlrpc.php' access.log

Hunderte Aufrufe am Tag von wechselnden Adressen, ohne dass du Jetpack oder eine App hast, sind das Raten von oben. Sie kosten Rechenzeit, und irgendwann trifft eines.

Sperren, wenn nichts es braucht#

Am Webserver, nicht im Plugin: Die Anfrage erreicht PHP dann gar nicht, es kostet nichts, und es gilt auch, wenn ein Plugin einmal deaktiviert ist.

Apache, in der .htaccess im Hauptverzeichnis (Apache 2.4):

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

nginx, im Serverblock:

location = /xmlrpc.php {
    deny all;
}

Beides antwortet mit 403. Wer lieber 404 sieht, nimmt bei nginx return 404; statt deny all;. Manche Hoster bieten im Kundenmenü einen Schalter dafür an; der tut dasselbe.

Die Datei zu löschen bringt nichts, WordPress legt sie beim nächsten Core-Update wieder hin. Dazu lässt sich die Kopfzeile X-Pingback abschalten, damit die Seite die Schnittstelle nicht mehr ankündigt, in einer Datei unter wp-content/mu-plugins/:

<?php
// wp-content/mu-plugins/kein-pingback.php
add_filter( 'wp_headers', function ( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

Drosseln, wenn Jetpack oder eine App es braucht#

Dann darf die Datei nicht gesperrt werden. Es bleiben vier Griffe, die sich kombinieren lassen:

Anmeldemethoden abschalten, Pingback entfernen. Der Filter xmlrpc_enabled schaltet laut Quelltext nur die Methoden ab, die eine Anmeldung verlangen; Pingbacks und andere Methoden ohne Anmeldung bleiben. pingback.ping nimmt man zusätzlich aus der Methodenliste, das ist der Weg, den Sucuri 2014 empfohlen hat:

<?php
// wp-content/mu-plugins/xmlrpc-begrenzen.php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

system.multicall registriert die Serverklasse selbst, nach diesem Filter; es lässt sich auf diesem Weg nicht entfernen. Für die WordPress-App ist das Abschalten der Anmeldemethoden keine Option, sie braucht sie. Bei Jetpack nach der Änderung im Jetpack-Menü prüfen, ob die Verbindung steht; Jetpack sagt nur, dass Sperren der Datei Probleme macht, nicht, welche Methoden es braucht.

Auf die Adressen von Jetpack begrenzen. Jetpack veröffentlicht die IP-Bereiche, aus denen es xmlrpc.php aufruft, als Liste zum Nachlesen und als maschinenlesbare Datei (jetpack.com/ips-v4.txt). Am 13.10.2026 waren das 122.248.245.244/32, 54.217.201.243/32, 54.232.116.4/32, 192.0.80.0/20, 192.0.96.0/20, 192.0.112.0/20, 195.234.108.0/22 und 192.0.64.0/18. Für Apache:

<Files "xmlrpc.php">
    Require ip 122.248.245.244 54.217.201.243 54.232.116.4 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20 195.234.108.0/22 192.0.64.0/18
</Files>

Die Liste gehört in den Kalender, Jetpack kann sie ändern. Für eine App vom Handy geht das nicht, deren Adresse wechselt.

Drosseln. Die WordPress-Dokumentation zeigt es für nginx mit derselben Zone, die auch wp-login.php bremst:

# im http-Block
limit_req_zone $binary_remote_addr zone=logins:10m rate=1r/s;

# im Serverblock
location = /xmlrpc.php {
    limit_req zone=logins burst=20 nodelay;
    # hier folgt die übliche PHP-Weitergabe
}

Bei Apache übernimmt das eine Web Application Firewall oder fail2ban, das Adressen mit vielen POST /xmlrpc.php im Zugriffsprotokoll zeitweise aussperrt.

Die Anmeldung selbst härten. Lange Passwörter und Zwei-Faktor-Anmeldung bleiben der Boden, auf dem alles andere steht. Welche Plugins die zweite Stufe auch bei XML-RPC durchsetzen, sagt deren Beschreibung; was sonst zur Härtung gehört, steht in WordPress-Sicherheit prüfen.

Was nicht hilft#

Die Datei löschen oder umbenennen. Das nächste Core-Update stellt sie wieder her.

Ein Security-Plugin, das xmlrpc.php sperrt, während Jetpack läuft. Jetpack nennt genau das als Ursache für Verbindungsfehler.

Nur die Kopfzeile X-Pingback verstecken. Wer die Datei sucht, findet sie im Hauptverzeichnis jeder WordPress-Seite, Kopfzeile hin oder her.

Ein Captcha auf der Anmeldeseite. Das sieht die Anmeldung über XML-RPC nicht.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Der Sicherheits-Check für 290 € nimmt die Außenansicht einer Website auseinander, Anmeldewege eingeschlossen, und liefert eine Liste mit Reihenfolge. Die WordPress-Wartung für 49 € im Monat hält danach Updates und Überwachung am Laufen. Ist die Anmeldung schon geknackt, ist das ein Fall für WordPress gehackt.

Häufige Fragen#

Stand 13.10.2026. WordPress-Quelltext (class-wp-xmlrpc-server.php, IXR-Serverklasse, class-wp.php), WordPress-Dokumentation, Jetpack-Hilfe, Trac-Ticket und die Sucuri-Beiträge von 2014 und 2015 an diesem Tag gelesen; eigene Messung an 21 Tiroler WordPress-Seiten am selben Tag.