Was ist xmlrpc.php, und wie deaktiviere ich XML-RPC in WordPress?

Warum das wichtig ist

XML-RPC ist eine alte Fernsteuerungsschnittstelle für WordPress. Bevor es die REST-API gab, veröffentlichten Desktop-Editoren und mobile Apps darüber Beiträge. Sie ist noch immer in jeder WordPress-Website enthalten, unter /xmlrpc.php, und nimmt noch immer bei jeder Anfrage einen Benutzernamen und ein Passwort an. Wer XML-RPC in WordPress deaktiviert oder zumindest den Login darüber schließt, schließt diese Tür.

Damit ist sie eine zweite Login-Tür. Das Verstecken von wp-login.php berührt sie nicht. Login-Limit-Code, der nur das Login-Formular überwacht, sieht sie nicht. Und mit system.multicall kann eine einzige HTTP-Anfrage Hunderte Passwortversuche transportieren. Ein Limit, das Anfragen zählt, sieht einen Versuch, wo es fünfhundert waren.

Das ist keine Theorie. Wir haben diese Ebene gebaut, nachdem ein Shop weiterhin Passwortversuche über XML-RPC erhielt, während seine Login-Seite bereits versteckt war.

Nutzt du XML-RPC? Wahrscheinlich nicht, wenn nichts davon auf dich zutrifft:

• Du verbindest die Website mit Jetpack.
• Du veröffentlichst oder moderierst über die offizielle WordPress-App.
• Du nutzt ein älteres Desktop-Blogging-Werkzeug oder einen Dienst, der deinen WordPress-Benutzernamen und dein Passwort verlangt (statt eines Anwendungspassworts), um in deinem Namen zu posten.
• Du bist auf Pingbacks von anderen Blogs angewiesen.

Wenn du unsicher bist, schließe nur den Login und behalte die Pingbacks. Damit ist das Risiko des Passwort-Ratens weg, und die harmlosen Teile bleiben erhalten. Strenger werden kannst du später immer noch.

Häufige Fehler

• Den Login verstecken und es dabei belassen. Das Passwort-Raten wandert einfach zu xmlrpc.php.
• Die ganze Datei ungeprüft blockieren. Jetpack und die offizielle WordPress-App verbinden sich über XML-RPC. Wenn du sie nutzt, schließe nur die Login-Methoden oder teste sorgfältig.
• Einem Schalter ungetestet vertrauen. Manche Methoden lassen Teile von XML-RPC weiter antworten. Prüfe das Ergebnis immer mit einer echten Anfrage (siehe Schritt 4 oder prüfen, was deine Website preisgibt).
• Die Cache-Ebene vergessen. Blockiert schon eine CDN-Regel xmlrpc.php, zeigt eine Einstellung auf WordPress-Ebene keine Wirkung. Das ist in Ordnung; wisse nur, welche Ebene die Arbeit macht.

Ohne Plugin

Option 1: der Filter xmlrpc_enabled. Füge das in ein kleines Must-use-Plugin (wp-content/mu-plugins/no-xmlrpc-login.php) oder die functions.php deines Child-Themes ein:

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

Das deaktiviert XML-RPC-Methoden, die eine Anmeldung erfordern. Pingbacks funktionieren weiter, weil sie keine brauchen. Für sich allein entfernt es system.multicall nicht, und die Datei beantwortet weiterhin Anfragen. Um auch die Multicall-Methode zu entfernen:

<?php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Option 2: die Datei auf dem Server blockieren. Unter Apache in der .htaccess:

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

Unter Nginx: location = /xmlrpc.php { deny all; }. Das ist die strengste Option und kostet den Server nichts, legt aber auch Pingbacks, Jetpack und die App lahm – und sie liegt außerhalb von WordPress, gerät also beim Hosterwechsel leicht in Vergessenheit.

Wenn etwas schiefgeht

• Jetpack zeigt einen Verbindungsfehler. Jetpack braucht XML-RPC. Wechsle von „Komplett deaktivieren“ zu „Login deaktivieren, Pingbacks behalten“ oder entferne deine Serverregel.
• Die WordPress-App kann sich nicht anmelden. Dieselbe Ursache. Nutze entweder den Browser auf dem Handy oder erlaube den XML-RPC-Login und verlass dich auf Login-Limits plus Zwei-Faktor-Authentifizierung.
• Ein Publishing-Werkzeug postet nicht mehr. Prüfe, ob es XML-RPC nutzt. Die meisten modernen Werkzeuge sind auf die REST-API mit Anwendungspasswörtern umgestiegen.

Mit Hushfort

Die Hintertür-Sperre gehört zu Hushfort Pro. Der Angriffsflächen-Scan, der zeigt, ob XML-RPC offen ist, steckt in Hushfort Security, dem kostenlosen WordPress-Sicherheitsplugin.

Die Hintertür-Sperre ist Teil der Ebene Angriffsflächen-Härtung von Hushfort. Sie bietet dir vier Optionen:

• Login deaktivieren, Pingbacks behalten (empfohlen): Passwort-Raten über XML-RPC wird unmöglich, Pingbacks und Trackbacks funktionieren weiter. Passt gut zu Shops.
• Komplett deaktivieren: die strengste Option. Jetpack und die offizielle App können sich nicht verbinden.
• Nur system.multicall deaktivieren: schließt das Massen-Raten und lässt den Rest unberührt.
• Nicht ändern: der WordPress-Standard.

Der Angriffsflächen-Scan prüft das Ergebnis anschließend mit echten Anfragen, sodass du siehst, was ein Außenstehender sieht. Der Lastschutz bepreist xmlrpc.php-Anfragen außerdem höher als einen normalen Seitenaufruf, was verbleibenden Lärm ausbremst.