Ihre Website ist träge, Ihr Hosting-Provider sendet Warnungen zu überschrittenen Limits, und die Logs zeigen einen endlosen Strom von POST-Anfragen an xmlrpc.php. Wenn Sie WordPress administrieren, dürfte Ihnen dieser Albtraum bekannt vorkommen.

Die Datei xmlrpc.php ist ein unscheinbares, aber äußerst gefährliches Element jeder WordPress-Installation. Sie befindet sich seit der CMS-Installation im Wurzelverzeichnis Ihrer Website und ist seit Jahrzehnten ein bevorzugter Einstiegspunkt für Bots und Angreifer. Laut dem Wordfence-Bericht 2024 gehören XML-RPC-Angriffe zu den fünf größten Bedrohungsvektoren für WordPress-Websites, und daran hat sich auch 2026 nichts geändert.

Dennoch wissen die meisten Website-Betreiber nicht, warum diese Datei überhaupt existiert oder wie man sie unschädlich macht. Dieser Leitfaden behandelt vier funktionierende Methoden, um xmlrpc.php zu blockieren, von einer schnellen .htaccess-Regel bis hin zu einer Firewall auf CDN-Ebene. Kein überflüssiger Inhalt, nur getesteter Code und Erläuterungen, wann welche Methode einzusetzen ist.

💡 Kurzer Überblick:

• Prüfen Sie, ob Ihre xmlrpc.php auf POST-Anfragen antwortet (was sie wahrscheinlich tut)
• Wählen Sie eine Blockiermethode: htaccess, Code in functions.php, Plugin oder WAF
• Fügen Sie die Blockierregel hinzu und verifizieren Sie, dass der Endpunkt 403 Forbidden zurückgibt
• Wenn Sie Jetpack nutzen, konfigurieren Sie einen gezielten Firewall-Schutz, anstatt die Datei vollständig zu deaktivieren

Was ist xmlrpc.php und warum ist sie immer noch in WordPress

XML-RPC (Remote Procedure Call) ist ein Protokoll, das externen Anwendungen die Kommunikation mit WordPress ermöglicht. Es wurde bereits in Version 1.5 in den Kern aufgenommen und diente jahrzehntelang als einzige API für Remote-Publishing: WordPress-Mobile-Apps, Desktop-Clients wie Windows Live Writer und Drittanbieterdienste waren alle darauf angewiesen.

Mit der Veröffentlichung der WordPress REST API in Version 4.7 (2016) entfiel die Notwendigkeit für XML-RPC weitgehend. Die moderne REST API deckt alles ab, was XML-RPC früher leistete, und zwar sicherer, schneller und mit ordnungsgemäßer Authentifizierung per Nonce oder OAuth.

Doch die Datei xmlrpc.php befindet sich weiterhin im Wurzelverzeichnis jeder WordPress-Installation. Remote-Publishing darüber ist standardmäßig deaktiviert, dennoch nimmt der Endpunkt Anfragen entgegen. Öffnen Sie einfach yoursite.com/xmlrpc.php in einem Browser, um zu sehen: „XML-RPC server accepts POST requests only". Das bedeutet, der Endpunkt ist aktiv und bereit für Angriffe.

Warum xmlrpc.php gefährlich ist: die Hauptangriffsvektoren

Angreifer nutzen xmlrpc.php für zwei Hauptarten von Angriffen, und beide können Ihre Website lahmlegen.

Brute-Force über system.multicall. Die Methode system.multicall erlaubt es, Hunderte von Authentifizierungsversuchen in EINE HTTP-Anfrage zu packen. Anstatt Passwörter einzeln zu testen (wie über wp-login.php), sendet ein Bot ein Array aus Logins und Passwörtern auf einmal. Standard-Plugins zur Login-Begrenzung erkennen solche Anfragen nicht, für sie sieht es nach „einem Versuch" aus. Ergebnis: Angreifer probieren Tausende von Kombinationen in Sekunden durch, ohne Sperren auszulösen.

Pingback-DDoS. Die Pingback-Funktion erlaubt es einer anderen Website, Ihr WordPress über einen Link darauf zu benachrichtigen. Ein Angreifer sendet eine gefälschte Pingback-Anfrage und setzt die IP-Adresse des Opfers als „Quelle" ein. Ihr Server macht sich pflichtgemäß daran, den Link zu verifizieren, und attackiert einen ahnungslosen Zielhost. Skaliert man dies über Tausende kompromittierter WordPress-Installationen, erhält man einen verteilten DDoS-Angriff, bei dem Ihre Website als Kanonenfutter dient.

Hosting-Provider verfolgen ausgehenden Datenverkehr dieser Art und können Ihren Account wegen „Teilnahme an DDoS" sperren. Währenddessen verschwendet Ihr Server CPU, Arbeitsspeicher und Bandbreite für die Verarbeitung von Junk-Anfragen.

Prüfung: Antwortet Ihre xmlrpc.php

Bevor Sie blockieren, stellen Sie sicher, dass der Endpunkt tatsächlich offen ist. Öffnen Sie dies in Ihrem Browser:

1
https://yoursite.com/xmlrpc.php

Wenn Sie die Zeichenkette „XML-RPC server accepts POST requests only" sehen, ist der Endpunkt aktiv und Angreifer können Anfragen dorthin senden. Erhalten Sie 403 Forbidden oder 404, funktioniert der Schutz bereits.

Zweite Methode: Senden Sie eine Test-POST-Anfrage per Terminal:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Eine Antwort mit 200 OK und einer XML-Struktur bestätigt: XML-RPC nimmt Anfragen entgegen und ist bereit zur Ausnutzung.

Methode 1: Schnelle Blockierung per.htaccess

Die einfachste und effektivste Methode ist, den Zugriff auf die Datei auf Webserver-Ebene zu blockieren. Die Anfrage wird abgewiesen, bevor sie WordPress erreicht, was Serverressourcen spart und selbst unter Last funktioniert.

Fügen Sie dies zu Ihrer .htaccess im Wurzelverzeichnis hinzu (die neben der wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Die Direktive Require all denied ist Apache-2.4+-Syntax und für alle modernen Hosting-Provider aktuell. Öffnen Sie nach dem Speichern xmlrpc.php in Ihrem Browser; Sie sollten 403 Forbidden erhalten.

Wenn Ihr Server mit nginx läuft, fügen Sie die Regel zur Virtual-Host-Konfiguration hinzu:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Denken Sie nach der Änderung der nginx-Konfiguration daran, den Server neu zu laden: sudo nginx -s reload.

Diese Methode funktioniert, wenn Sie XML-RPC DEFINITIV nicht benötigen, weder für Jetpack noch für WordPress-Mobile-Apps noch für WooCommerce-Integrationen.

Methode 2: Deaktivierung per functions.php (programmatische Methode)

Wenn Sie das Problem lieber auf Code-Ebene statt über Serverkonfigurationen lösen möchten, finden Sie hier zwei getestete Snippets für die functions.php Ihres aktiven Themes oder Code Snippets.

Vollständige XML-RPC-Deaktivierung (WP 3.5+):

1
// Disable XML-RPC completely
2
add_filter('xmlrpc_enabled', '__return_false');

Eine Zeile, und WordPress verarbeitet keine XML-RPC-Anfragen mehr. Beim Versuch, auf xmlrpc.php zuzugreifen, erhält der Client eine Fehlerantwort; die Datei selbst bleibt auf dem Server, ist aber funktional tot.

Bereinigung der wp_head-Header von RSD- und WLW-Links:

Selbst nach der Deaktivierung fügt XML-RPC WordPress weiterhin zwei Zeilen in <head> ein, die Informationen über Ihre Website preisgeben:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Die Hooks rsd_link und wlwmanifest_link fügen <link rel="EditURI">- und <link rel="wlwmanifest">-Tags in <head> ein; diese existieren ausschließlich für XML-RPC-Clients und erfüllen 2026 keinen praktischen Zweck mehr. Entfernen Sie sie.

⚠️ Wichtig: Bearbeitungen an der functions.php des Themes gehen bei einem Update verloren. Verwenden Sie ein Child-Theme oder das Plugin Code Snippets für die dauerhafte Speicherung von benutzerdefiniertem Code.

Methode 3: Sicherheits-Plugins

Wenn Sie keinen Code anfassen möchten, installieren Sie ein Plugin. Drei getestete Optionen:

• Wordfence Security. Die beliebteste WordPress-Firewall. Neben der Blockierung von XML-RPC bietet sie einen Malware-Scanner, Login-Schutz und Traffic-Überwachung. In den Wordfence-Einstellungen unter Login Security → aktivieren Sie „Disable XML-RPC authentication".

• Disable XML-RPC-API. Ein schlankes Plugin, das genau eine Sache tut: Es hängt sich in den Filter xmlrpc_enabled ein und deaktiviert den Endpunkt. Keine weiteren Einstellungen; aktivieren und vergessen.

• iThemes Security (Solid Security). Ein umfassendes Plugin mit einem WordPress-Tweaks-Modul, in dem XML-RPC mit einer einzigen Checkbox deaktiviert wird. Es schließt auch andere Vektoren: Änderung des Tabellenpräfixes, Deaktivierung des Datei-Editors aus dem Admin-Bereich, Brute-Force-Schutz.

Überprüfen Sie nach der Aktivierung eines dieser Plugins stets, dass xmlrpc.php einen Fehler zurückgibt, keine Begrüßung.

Methode 4: Blockierung auf Firewall-Ebene (Cloudflare / Sucuri)

Die mächtigste Schutzebene ist eine Web-Firewall, die bösartige Anfragen verwirft, bevor sie überhaupt Ihr Hosting erreichen.

Cloudflare** WAF.** Erstellen Sie eine benutzerdefinierte Regel: Feld URI Path enthält xmlrpc.php → Aktion Block. Anfragen werden auf Netzwerkebene von Cloudflare gefiltert (über 330 Points of Presence weltweit); Ihr Server sieht sie nie. Der Free-Tarif umfasst 5 benutzerdefinierte Regeln, was ausreicht. Bonus: Cloudflare zeigt Statistiken zu blockierten Anfragen, und Sie können das Ausmaß des Angriffs mit eigenen Augen sehen.

Sucuri Website Firewall. Ähnlicher Ansatz: eine WAF-Regel auf die URI /xmlrpc.php. Sucuri bietet zudem Dateiintegritätsüberwachung und automatische Malware-Bereinigung.

Eine Firewall-Regel funktioniert gut in Kombination mit .htaccess oder programmatischer Deaktivierung: Die Firewall schneidet den Massen-Junk ab, während die lokale Sperre als Rückfallebene dient, falls Traffic die WAF irgendwie umgeht.

Was tun, wenn Sie Jetpack nutzen

Jetpack von Automattic verwendet XML-RPC, um Ihre Website mit den Servern von WordPress.com zu verbinden. Wenn Sie xmlrpc.php vollständig deaktivieren, stellt Jetpack den Dienst ein: Statistiken, Abonnements, Bild-CDN, das Modul „Ähnliche Beiträge" und der Brute-Force-Schutz von Jetpack fallen alle auf einmal aus.

Die Lösung: XML-RPC nicht vollständig abwürgen, sondern Anfragen von Jetpack-Servern selektiv erlauben:

• Lassen Sie xmlrpc.php erreichbar (KEINE Blockierung per .htaccess und KEIN Einhängen in den Filter xmlrpc_enabled).

• Konfigurieren Sie die Cloudflare WAF wie folgt: Erlauben Sie Anfragen an xmlrpc.php NUR von den IP-Bereichen von Automattic (die Liste wird in der Jetpack-Dokumentation aktualisiert), blockieren Sie den Rest.

• Entfernen Sie mindestens die RSD- und WLW-Header mit dem Snippet aus Methode 2, damit Sie den Endpunkt nicht unnötig in <head> preisgeben.

• Installieren Sie Wordfence und aktivieren Sie den Brute-Force-Schutz speziell für xmlrpc.php; dies blockiert keine legitimen Jetpack-Anfragen, unterbindet aber Passwort-Erraten-Versuche.

⁉️🤔 Häufig gestellte Fragen

Kann ich die Datei xmlrpc.php einfach vom Server löschen?

Das können Sie, aber es ist schlechte Praxis. Beim nächsten WordPress-Update wird die Datei wiederhergestellt, und Sie sind erneut verwundbar. Besser ist es, den Zugriff per .htaccess zu blockieren oder die Funktionalität mit einem Filter im Code zu deaktivieren: Der Effekt ist derselbe, aber Kern-Updates zerstören Ihren Schutz nicht. Falls Sie die Datei doch gelöscht haben, entfernen Sie unbedingt rsd_link aus wp_head, sonst erhalten Besucher einen 404-Fehler, wenn sie dem EditURI-Link folgen.

Führt die Deaktivierung von XML-RPC zu Problemen mit WooCommerce?

Nein. WooCommerce ist vollständig auf die WordPress REST API umgestiegen und nicht von XML-RPC abhängig. Ihr Shop funktioniert unverändert weiter. Die einzige Ausnahme ist, wenn Sie eine uralte, an XML-RPC gebundene Individuallösung nutzen, aber davon existiert praktisch keine mehr.

Was, wenn mein Hosting-Provider xmlrpc.php bereits blockiert?

Wenn der Provider XML-RPC bereits auf Serverebene deaktiviert hat, müssen Sie nichts tun; der Endpunkt ist nicht erreichbar. Prüfung: Öffnen Sie xmlrpc.php; wenn Sie 403 sehen, funktioniert der Schutz. Das Einzige, was sich lohnt, ist das Entfernen der RSD- und WLW-Header per functions.php, denn der Provider kümmert sich nicht darum.

Muss ich XML-RPC deaktivieren, wenn ich Managed WordPress Hosting nutze?

Die meisten Managed Hosts (Kinsta, WP Engine, SiteGround) blockieren oder beschränken xmlrpc.php strikt auf Plattformebene. Prüfen Sie per Browser, ob der Endpunkt offen ist. Wenn blockiert, ist keine weitere Maßnahme erforderlich. Wenn offen, fügen Sie die .htaccess-Regel hinzu: Managed Hosts überschreiben diese nicht.

Wie erkenne ich, ob meine Website gerade über xmlrpc.php angegriffen wird?

Drei Anzeichen: ein starker Anstieg der Serverlast bei unverändertem Traffic, Hunderte identischer POST-Anfragen an xmlrpc.php in den Zugriffslogs sowie Fehler zu Speicher-/CPU-Limits von Ihrem Hosting-Provider. Aktivieren Sie die Überwachung (Wordfence → Live Traffic oder Cloudflare → Security Events); Sie sehen Quelle und Ausmaß des Angriffs in Echtzeit.

Lohnt es sich, xmlrpc.php im Jahr 2026 zu deaktivieren

Kurze Antwort: ja, wenn Sie Jetpack nicht nutzen und keine Beiträge über die WordPress-Mobile-App veröffentlichen.

XML-RPC ist ein Relikt aus der Ära von WordPress 1.5. Die REST API hat längst ihren Platz eingenommen, und xmlrpc.php selbst ist zu einer offenen Tür für Brute-Force- und DDoS-Angriffe geworden. Sie zu schließen, dauert fünf Minuten. Wählen Sie die Methode für Ihre Situation:

• Sie möchten keinen Code anfassen: Installieren Sie Disable XML-RPC-API, zwei Klicks.
• Sie haben Zugriff auf Serverdateien: Fügen Sie eine Regel in .htaccess ein, die Serverebene ist zuverlässiger.
• Sie bevorzugen sauberen Code: Wenden Sie den Filter xmlrpc_enabled an und entfernen Sie Header mit zwei Snippets in functions.php.
• Sie wünschen maximalen Schutz: Richten Sie eine WAF-Regel in Cloudflare ein und kombinieren Sie sie mit einer lokalen Sperre.

Überprüfen Sie nach der Blockierung stets, dass xmlrpc.php 403 Forbidden zurückgibt, und überwachen Sie die Logs mindestens eine Woche lang; Sie werden überrascht sein, wie viel Junk-Traffic verschwindet. Abonnieren Sie auch WordPress-Updates: Die Geschichte zeigt, dass alte Protokolle langsam sterben und neue XML-RPC-Schwachstellen auch nach 2026 noch auftauchen können.