Die Datei xmlrpc.php ist ein Kernbestandteil von WordPress und wird seit Version 3.5 (Release Date: 11.12.2012) standardmäßig aktiviert. Ursprünglich für Funktionen wie Remote-Blogging (z. B. mit mobilen Apps, externen Redaktionssystemen oder Jetpack) konzipiert, hat sie sich heute zum Ziel für zahlreiche Cyberangriffe entwickelt. Ihre grundlegende Architektur erlaubt es, über einfache HTTP-POST-Requests Remote-Befehle per XML zu übermitteln. Was komfortabel, aber zugleich riskant ist.
XML-RPC (Remote Procedure Call mittels XML und HTTP) wurde als universelle Schnittstelle für den Austausch zwischen verschiedenen Webanwendungen und WordPress eingeführt. Damit konnten beispielsweise Content-Systeme Inhalte einstellen oder Apps Daten abrufen, ohne dass ein interaktiver Login nötig war. Doch die offene Struktur und Funktionen wie system.multicall (mehrere Methoden in einem Request), pingback.ping und direkte Nutzerinteraktionen begünstigen Missbrauch.
Angriffsszenarien
1. Brute Force-Attacken
Angreifer nutzen die Möglichkeit, hunderte Anmeldeversuche (Username/Passwort) in einem einzigen Request zu bündeln und so deutlich schneller als über die reguläre Login-Seite Passwörter zu knacken. Die Methode wp.getUsersBlogs wird typischerweise verwendet, um automatisiert Zugänge zu kompromittieren. Bots scannen global hunderttausende Sites nach der Datei und starten automatisierte Angriffe. Die Sicherheitstools von Wordfence und Sucuri dokumentieren regelmäßig millionenfache Angriffsversuche auf xmlrpc.php, teils mehr als über die klassische Login-Seite.
DDoS und Reflection-Angriffe
Die pingback.ping Funktion ermöglicht es, beliebige DDoS-Attacken zu fahren: Ein Angreifer kann von tausenden legitimen WordPress-Sites gleichzeitig Pingbacks an eine Zielseite senden, wodurch der Server massiv überlastet und offline geht. Solche Angriffe wurden bereits 2014 und 2016 dokumentiert, bei denen über 162.000 kompromittierte Sites zu einem Botnetz für DDoS-Angriffe verbunden wurden
Remote Code Injection und Privilege Escalation
Speziell ältere Versionen von WordPress und PHP-Bibliotheken sind für Remote Code Execution (RCE) anfällig: XML-Daten werden vom Server ungefiltert interpretiert und können zu direkten Kommandos auf dem System führen (eval-Injection). Ebenso kann ein Angreifer durch Bugs wie CVE-2020-28036 oder CVE-2025-54352 privilegierte Aktionen ausführen, etwa über den Comment-Endpunkt oder das Auslesen geheimer Beitragsdaten.
Eindrücklich lässt sich das Gefährdungspotenzial an realen Fallstudien beobachten, etwa bei der Zscaler-Malware-Kampagne 2025. Über Botnetze wurde gezielt nach ungeschützten Installationen gesucht, um anschließend Zugangsdaten zu extrahieren und Schadcode zu platzieren.
Auch sind immer wieder größere Anbieter und Agenturen betroffen, weil xmlrpc.php selbst bei großen Seiten durch fehlerhafte Konfiguration lange angreifbar blieb. Cybersecurity-Forscher wie Wordfence und Sucuri weisen in jährlichen Reports darauf hin, dass globale Angriffswellen und gezielte Exploits für einen nicht unwesentlichen Teil der WordPress-Hacks verantwortlich sind.
Laut aktuellen Statistiken gehen 40–50% der automatisierten Angriffe auf WordPress-Webseiten direkt oder indirekt auf das Konto der xmlrpc.php, Tendenz steigend.
Weitere Angriffsvektoren
- Cross-Site Scripting (XSS):Schlecht validierte XML-RPC-Requests erlauben das Einschleusen von Code.
- Sensitive Data Leakage: Ungeschützte Transportschicht oder fehlerhafte Restriktionen können zu Datenverlust führen.
Die Lösung
Glücklicherweise ist es einfach, der xmlrpc.php den Garaus zu machen. Da WordPress diese Schnittstelle seit Version 3.5 standardmäßig aktiviert, die meisten Webseitenbetreiber diese Schnittstelle aber mittlerweile nicht mehr kennen, bleibt diese Sicherheitslücke "einfach offen". Wer seine Seite schützen möchte, kann die Schnittstelle ganz einfach deaktivieren.
Und das Beste: Es gibt mehrere unkomplizierte Wege, dies zu tun.
Variante 1: Deaktivierung via .htaccess
Für alle, die ihre WordPress-Seite auf einem Apache-Server betreiben, ist die Lösung denkbar einfach. Alles, was man tun muss, ist, folgenden Code in die .htaccess einzufügen.
Order Allow,
Deny Deny from all
< /Files >
Dieser Code blockiert den Zugriff auf die xmlrpc.php vollständig. Damit bleibt die Schnittstelle geschlossen, und niemand kann sie für Angriffe nutzen.
Variante 2: Deaktivierung via NGINX-Direktive
Wer auf einem NGINX-Server arbeitet, kann die folgende Direktive in die Server-Konfiguration einfügen:
Auch hier wird der Zugriff auf die Datei unterbunden, was die Sicherheit der Seite erheblich erhöht.
Variante 3: Deaktivierung über die functions.php
Die dritte Möglichkeit ist eine besonders simple Methode für die meisten WordPress-Nutzer, die keine großen Änderungen an der Server-Konfiguration vornehmen möchten. Ein kleiner Code in der functions.php reicht aus, um die XML-RPC-Schnittstelle zu deaktivieren:
Dieser Code sorgt dafür, dass die XML-RPC-Schnittstelle in WordPress selbst deaktiviert wird. Das hat denselben Effekt wie die anderen Methoden und ist vor allem dann praktisch, wenn man keine direkten Änderungen an der Server-Konfiguration vornehmen möchte.
Sicherheit geht vor
Die Schutzempfehlungen der Security-Community fallen inzwischen eindeutig aus: Wer keine zwingende Notwendigkeit für die xmlrpc.php hat, sollte den Zugriff darauf konsequent blockieren. Möglich ist das mit einfachen .htaccess-Regeln für Apache, Direktiven für NGINX oder einem WordPress-Filter, der die Schnittstelle deaktiviert.
Ergänzend bieten viele Sicherheits-Plugins wie iThemes Security oder Shield Security weitergehende Kontrollmechanismen, etwa das temporäre Freischalten auf Wunsch oder detailliertes Logging. Besonders großer Wert sollte außerdem auf regelmäßige Updates gelegt werden.
Denn viele bekannte Sicherheitslücken, darunter auch Privilege Escalation und Remote Code Execution, wurden erst in den aktuelleren WordPress-Releases geschlossen.
Insgesamt ist xmlrpc.php ein Paradebeispiel für das Dilemma zwischen moderner Webfunktionalität und IT-Sicherheit. Was einmal als technische Innovation und Beitrag zur offenen Webarchitektur gedacht war, ist heute in vielen Fällen ein Relikt aus einer weniger sicheren Zeit und ein beliebtes Ziel für Cyberkriminalität.
Wer WordPress heute sicher betreiben will, sollte diesen Vektor nicht außer Acht lassen und die Schnittstelle falls möglich deaktivieren oder ihren Zugang zumindest restriktiv überwachen. Die dokumentierten Angriffe und prominenten Vorfälle der letzten Jahre zeigen, dass dies nicht nur theoretischer Natur ist, sondern ganz unmittelbare Auswirkungen auf Verfügbarkeit, Integrität und Reputation einer jeden Website haben kann.