WordPress xmlrpc.php deaktivieren – Angriffe abwehren

Die Datei xmlrpc.php liegt seit jeher in jedem WordPress-Hauptverzeichnis. Sie war einmal wichtig — heute ist sie für die meisten Websites nur noch eines: eine offene Flanke. Wer sie nicht braucht (und das sind fast alle), schließt sie am besten.

Warum xmlrpc.php ein Problem ist

• Verstärkte Brute-Force-Angriffe: Über die Methode system.multicall lassen sich hunderte Login-Versuche in einer einzigen Anfrage bündeln. Klassische Login-Begrenzungen zählen aber Anfragen — nicht Versuche. Angreifer testen so tausende Passwörter unterhalb des Radars.
• Pingback-Missbrauch: Die Pingback-Funktion lässt sich nutzen, um deine Website als Teil eines DDoS-Angriffs auf Dritte einzuspannen — dein Server greift dann fremde Ziele an.
• Ein zweiter Login-Weg: Alles, was du an wp-login.php absicherst (Captcha, 2FA-Formulare, Umbenennung), läuft ins Leere, wenn die Anmeldung per XML-RPC weiter offen ist.

Brauchst du xmlrpc.php noch?

Die kurze Liste der legitimen Nutzer:

• Jetpack (verbindet sich klassisch über XML-RPC),
• die alte WordPress-Mobile-App auf Alt-Installationen (die aktuelle nutzt die REST-API),
• einige Fernpublikations-Tools (Open Live Writer & Co.) und vereinzelte Verwaltungsdienste.

Nutzt du nichts davon — und das ist der Normalfall —, kannst du die Schnittstelle gefahrlos schließen. Moderne Integrationen laufen über die REST-API, die davon unberührt bleibt.

Sauber deaktivieren: die Wege

1. Per .htaccess blockieren (empfohlen): Der Server weist Anfragen ab, bevor PHP überhaupt startet — das spart auch Ressourcen bei Angriffswellen:
   <Files xmlrpc.php>
Require all denied
</Files>
2. Per Filter abschalten: In der functions.php (besser: im Child Theme) oder als Mini-Plugin:
   add_filter('xmlrpc_enabled', '__return_false');
   Das deaktiviert die Authentifizierung über XML-RPC; die Datei bleibt erreichbar, antwortet aber abweisend.
3. Nur Pingbacks abschalten (falls du XML-RPC teilweise brauchst):
   add_filter('xmlrpc_methods', function($methods) { unset($methods['pingback.ping']); return $methods; });
4. Ausnahme für Jetpack: Wenn Jetpack im Einsatz ist, blockiere nicht pauschal, sondern begrenze den Zugriff auf die IP-Bereiche von Automattic — oder nutze die Firewall-Funktion eines Sicherheits-Plugins, die genau diese Ausnahme mitbringt.

Testen, ob es wirkt

Rufe deine-domain.de/xmlrpc.php im Browser auf:

• Vorher: „XML-RPC server accepts POST requests only.“ — Schnittstelle aktiv.
• Nachher (bei .htaccess-Block): 403 Forbidden — Ziel erreicht.

Wirf danach einen Blick in die Server-Logs: Auf vielen Websites prasseln täglich hunderte xmlrpc-Anfragen ein — jede davon läuft jetzt ins Leere.

Einordnung: ein Baustein, kein Schutzschild

xmlrpc.php zu schließen ist ein sinnvoller, kostenloser Härtungsschritt — aber eben einer von vielen. Ohne aktuelle Plugins, starke Passwörter und Login-Begrenzung bleibt die Tür daneben offen. Das Gesamtpaket zählt: Updates, Härtung, Scans, Überwachung.

Im Shield-Modul von Ammera Care gehört der XML-RPC-Block zur 1-Klick-Härtung — zusammen mit Security-Headern, Login-Schutz, täglichem Malware-Scan und Schwachstellen-Abgleich. Ein Klick, dokumentiert, rückholbar. Zum Shield-Modul.