Jede WordPress-Installation speichert eine „stille" Datei im Wurzelverzeichnis, die die meisten Betreiber erst nach einem Angriff entdecken. Ihr Name lautet xmlrpc.php. Die Datei selbst ist nicht bösartig: WordPress weist ehrlich darauf hin, dass es sich um eine Schnittstelle für entfernte Interaktionen handelt. Doch genau über diese Datei betreiben Bots seit Jahren Brute-Force-Angriffe auf Passwörter, versenden Spam-Pingbacks und verursachen DDoS-Traffic.

Laut Wordfence-Daten für 2024 gehören Angriffe via XML-RPC zu den fünf häufigsten Angriffsvektoren gegen WordPress-Seiten. Eine einzige system.multicall-Anfrage erlaubt es einem Angreifer, hunderte Passwörter auf einmal zu testen, statt nur eines wie über das Login-Formular. Hosting-Anbieter registrieren monatlich Millionen solcher Versuche auf einer durchschnittlichen Website.

Lassen Sie uns verstehen, wofür diese Datei überhaupt benötigt wird, wer sie behalten sollte, und vor allem fünf Wege aufzeigen, xmlrpc.php zu deaktivieren oder sicher zu blockieren, von einem Ein-Klick-Plugin bis hin zu gezielten .htaccess-Anpassungen.

💡 Kurzübersicht:

• Erfahren Sie, was xmlrpc.php ist und welche WordPress-Funktionen davon abhängen (Pingback, mobile App, Jetpack)
• Bewerten Sie die realen Risiken: Brute-Force-Verstärkung, Pingback-DDoS und Verzeichnis-Scanning durch Bots
• Wählen Sie die passende Schutzmethode: Deaktivierung per Plugin, Blockierung über .htaccess, Zugriffssperre auf Webserver-Ebene oder Entfernen der Datei
• Monitoring einrichten: Wie Sie sicherstellen, dass xmlrpc.php nicht mehr auf Anfragen reagiert

Was xmlrpc.php ist und welche WordPress-Funktionen davon abhängen

XML-RPC ist ein Protokoll für entfernte Prozeduraufrufe, das über HTTP arbeitet und Daten im XML-Format überträgt. Die Technologie entstand Ende der 1990er Jahre, lange vor der REST API, und WordPress hat sie in seinen Anfangstagen übernommen. Die Datei xmlrpc.php im Wurzelverzeichnis der Website nimmt XML-Anfragen entgegen, verarbeitet sie und gibt eine Antwort zurück, veröffentlicht beispielsweise einen Beitrag, lädt eine Mediendatei hoch oder prüft Benutzerberechtigungen.

In der Praxis laufen mehrere Szenarien über xmlrpc.php:

• Pingbacks und Trackbacks. Wenn jemand auf Ihren Beitrag verlinkt, sendet dessen Website eine XML-RPC-Anfrage mit einer Benachrichtigung. Ihr WordPress prüft den Link und fügt den Pingback, sofern er echt ist, den Kommentaren hinzu.

• Entfernte Veröffentlichung. Anwendungen wie der alte Windows Live Writer oder Desktop-Clients (TextMate, MarsEdit) nutzten XML-RPC, um Beiträge zu schreiben und zu versenden, ohne das Admin-Panel zu betreten.

• WordPress Mobile App. Die offizielle iOS- und Android-App setzte lange Zeit auf XML-RPC, auch wenn sie inzwischen zunehmend auf die REST API umstellt.

• Integrationen. Dienste wie Jetpack (ein Teil seiner Funktionalität), IFTTT und einige SEO-Tools nutzen XML-RPC weiterhin, um sich mit der Website zu verbinden.

Mit der Veröffentlichung der WordPress REST API in Version 4.7 (Dezember 2016) sind die meisten modernen Integrationen auf das neue Protokoll umgestiegen. Die REST API ist schneller, arbeitet mit JSON statt XML und ist besser dokumentiert. Dennoch enthält WordPress xmlrpc.php aus Gründen der Abwärtskompatibilität weiterhin in jeder Installation.

Wichtige Nuance: Seit WordPress 2.6 (bereits 2008) ist die entfernte Veröffentlichungsfunktion via XML-RPC standardmäßig deaktiviert. Um sie zu aktivieren, müssen Sie explizit das Häkchen unter „Einstellungen → Schreiben" setzen. Pingbacks und Trackbacks funktionieren gleichzeitig weiter.

Wie xmlrpc.php gefährlich ist: drei Hauptangriffsvektoren

Die WordPress-Entwickler haben xmlrpc.php mehrfach gepatcht. In Version 2.1.2 konnte ein authentifizierter Benutzer mit „Mitwirkender"-Rechten einen Beitrag unter Umgehung von Beschränkungen veröffentlichen. In 2.3.1 entdeckte man ein Informationsleck über XML-RPC. Beide Lücken wurden schnell geschlossen, aber das Protokoll selbst blieb architektonisch anfällig für drei Angriffsklassen, die auch 2026 noch relevant sind.

Brute-Force-Verstärkung via system.multicall

Das Hauptproblem ist die Methode system.multicall. Sie erlaubt es, mehrere wp.getUsersBlogs-Aufrufe in eine HTTP-Anfrage zu packen. Jeder Aufruf prüft ein Paar aus „Benutzername + Passwort". So führt der Angreifer statt eines Versuchs pro Anfrage hunderte durch. Cloudflare hat Spitzen von zehntausenden solcher Anfragen pro Stunde auf einer einzelnen Website verzeichnet.

Das normale Login-Formular wp-login.php ist auf einen Login pro Versuch beschränkt und lässt sich leicht durch ein Plugin wie Wordfence oder Limit Login Attempts schützen. xmlrpc.php umgeht all diese Begrenzer, weil es über einen anderen Endpunkt arbeitet.

Pingback-DDoS

Die Pingback-Funktion ist als harmlose Benachrichtigung konzipiert. Ein Angreifer kann jedoch gefälschte Pingback-Anfragen im Namen hunderter Websites versenden, und Ihr Server wird jeden „Link" überprüfen, was CPU, Netzwerk und Datenbank belastet. Bei ausreichender Skalierung geht die Website offline. Sucuri bezeichnet Pingback-Angriffe in seinem Bericht von 2023 als einen der häufigsten DDoS-Vektoren gegen WordPress.

Verzeichnis-Scanning durch Bots

Bots suchen xmlrpc.php nicht nur im Wurzelverzeichnis, sondern auch in erfundenen Unterverzeichnissen wie /2026/01/xmlrpc.php und /blog/xmlrpc.php. Jede solche Anfrage liefert einen 404-Fehler und verschwendet Serverressourcen. Selbst wenn der Angriff fehlschlägt, verlangsamen zehntausende Junk-Anfragen die Website und verstopfen die Logs. In der Praxis sehen Betreiber, wie die Graphen in cPanel in den roten Bereich gehen, und der Grund sind genau Bots, die xmlrpc.php scannen.

5 Wege, xmlrpc.php zu deaktivieren oder abzusichern

Nachfolgend fünf Methoden, von der einfachsten bis zur radikalsten. Wählen Sie je nach Ihrer Situation: ob Sie die mobile App nutzen, ob Sie Pingbacks benötigen, welches Hosting Sie haben.

1. Deaktivierung per Plugin

Der sicherste Weg für diejenigen, die den Code nicht anfassen möchten. Installieren Sie ein Plugin, und es blockiert den Zugriff auf xmlrpc.php auf WordPress-Ebene, bevor die Anfrageverarbeitung beginnt.

Vorteile: Keine Notwendigkeit, .htaccess oder functions.php zu bearbeiten, einfach wieder einschaltbar. Nachteile: Fügt dem Admin-Panel ein weiteres Plugin hinzu, der Schutz entfällt bei Deaktivierung.

Einige bewährte Optionen:

• Disable XML-RPC, minimalistisch, eine Aktion: aktiviert, und der Zugriff ist gesperrt. Keine Einstellungen.
• Wordfence Security, umfassende Firewall, in der das Deaktivieren von XML-RPC nur eine der Funktionen ist. Geeignet, wenn Sie Wordfence bereits nutzen oder die Installation planen.

2. Blockierung via.htaccess

Wenn Sie auf einem Apache-Server arbeiten, erlaubt Ihnen die .htaccess-Datei im Wurzelverzeichnis der Website, den Zugriff zu blockieren, bevor die Anfrage WordPress erreicht. Das reduziert die Last: Apache gibt sofort 403 Forbidden zurück, ohne PHP auszuführen.

Fügen Sie den folgenden Block am Anfang der Datei in .htaccess ein, vor # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

Die Direktive RedirectMatch 403 fängt jede URL ab, die auf /xmlrpc.php endet, einschließlich Unterverzeichnissen wie /2025/06/xmlrpc.php, und gibt sofort 403 zurück.

Vorteile: Berührt den WordPress-Code nicht, arbeitet vor dem Laden von PHP, spart Ressourcen. Nachteile: Erfordert manuelle Bearbeitung von .htaccess, bei Hosting- oder Theme-Wechsel kann die Datei überschrieben werden.

Wichtig: Erstellen Sie vor der Bearbeitung von .htaccess ein Backup. Ein Syntaxfehler in .htaccess kann die Website lahmlegen (500 Internal Server Error).

3. Links via functions.php entfernen

Diese Methode blockiert nicht die Datei selbst, sondern entfernt HTML-Links zu xmlrpc.php und wlwmanifest.xml aus dem <head>-Bereich der Website. Der Nutzen liegt in der verringerten Sichtbarkeit: Bots, die HTML parsen, sehen keinen direkten Hinweis auf den XML-RPC-Endpunkt.

Fügen Sie dies in die functions.php des aktiven Themes ein (oder über das Code Snippets-Plugin):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

Der rsd_link-Hook gibt <link rel="EditURI"> aus, einen Link zu xmlrpc.php für Really Simple Discovery-Clients. Der wlwmanifest_link-Hook ist für Windows Live Writer (seit langem nicht mehr unterstützt, aber WordPress gibt ihn immer noch aus).

Vorteile: Sauberer <head> ohne überflüssige Links. Nachteile: xmlrpc.php bleibt physisch über die direkte URL erreichbar, dies ist keine Blockierung, sondern Maskierung.

4. Zugriff via WAF oder Cloudflare sperren

Eine Web Application Firewall blockiert Anfragen an xmlrpc.php, bevor sie Ihren Server erreichen. Dies ist der effektivste Ansatz für Websites auf jedem Hosting.

Konfigurationsoptionen:

• Cloudflare (kostenloses Tarifmodell): WAF-Regel → Blockieren → Feld URI-Pfad enthält /xmlrpc.php. Die Anfrage wird auf Cloudflare-Netzwerkebene abgewiesen, Ihr Server sieht sie gar nicht erst.
• Wordfence WAF: Integrierte Funktion „XML-RPC deaktivieren" im Firewall-Bereich.
• Hosting-WAF: Kinsta, WP Engine und andere Managed-Hoster erlauben es, XML-RPC mit wenigen Klicks über das Control Panel zu deaktivieren.

Vorteile: Keine Serverlast, fein abstimmbar (zum Beispiel Jetpack erlauben, während alles andere blockiert wird). Nachteile: Erfordert Konfiguration auf WAF-Seite, nicht alle Hosting-Anbieter bieten diese Möglichkeit.

5. Die Datei selbst entfernen oder umbenennen

Die radikalste Methode. Sie löschen (oder benennen) die Datei xmlrpc.php vom Server. Wenn die Datei physisch nicht existiert, gibt es nichts, was die Anfragen verarbeitet, der Server liefert 404.

Wichtige Nuance: Beim nächsten WordPress-Update wird die Datei wiederhergestellt. Automatische Core-Updates überschreiben alle WordPress-Dateien, einschließlich xmlrpc.php. Daher ist die Löschung eine temporäre Maßnahme, es sei denn, Sie richten eine regelmäßige Bereinigung ein.

Wenn Sie diesen Weg gehen, ergänzen Sie die Löschung mit der .htaccess-Regel aus Methode 2. Ohne sie klopfen Bots weiterhin an die xmlrpc.php-URL, und der Server liefert bei jeder Anfrage brav einen 404-Fehler, was zu tausenden Fehlern in den Logs führt.

Lohnt es sich überhaupt, xmlrpc.php zu deaktivieren?

Die Antwort hängt davon ab, was Sie nutzen. Gehen Sie die Checkliste durch:

Wenn Sie keine alte Version der mobilen App nutzen, die Jetpack-Verwaltung mit WordPress.com nicht aktiviert haben und Pingbacks für Sie nicht kritisch sind, deaktivieren Sie die Datei ohne Zögern. Im Jahr 2026 deckt die REST API nahezu alle realen Szenarien ab.

Video: So deaktivieren Sie XML-RPC in WordPress in 5 Minuten

Sehen Sie sich eine visuelle Anleitung zur Deaktivierung von xmlrpc.php mit Bildschirmdemonstration und Erklärung jeder Methode an:

⁉️🤔 Häufig gestellte Fragen

Ist es sicher, xmlrpc.php einfach zu ignorieren?

In den meisten Fällen nein. Selbst wenn Sie XML-RPC nicht nutzen, scannen Bots diesen Endpunkt ständig. Jede solche Anfrage belastet den Server. Besser, Sie sperren den Zugriff explizit via .htaccess oder Plugin, das beseitigt sowohl das Brute-Force-Risiko als auch die Junk-Anfragen in den Logs.

Geht die Website kaputt, wenn xmlrpc.php deaktiviert wird?

WordPress selbst funktioniert ohne Änderungen weiter. Prüfen Sie lediglich, ob Sie die Jetpack-Verwaltung mit WordPress.com oder eine alte Version der mobilen App nutzen. Wenn nicht, deaktivieren Sie die Datei bedenkenlos. Pingbacks werden nicht mehr eingehen, aber die meisten Websites nutzen sie ohnehin nicht für echte Kommunikation.

Wie prüfe ich, dass xmlrpc.php tatsächlich blockiert ist?

Öffnen Sie in Ihrem Browser https://your-site.com/xmlrpc.php. Wenn Sie einen weißen Bildschirm mit der Meldung „XML-RPC server accepts POST requests only" sehen, ist die Datei aktiv und antwortet. Erhalten Sie 403 Forbidden oder 404 Not Found, funktioniert die Blockierung. Für automatisches Monitoring können Sie Online-Checker wie xmlrpc.eror.xyz oder eine curl-Anfrage aus der Konsole nutzen.

Was ist besser: Plugin oder.htaccess?

.htaccess blockiert die Anfrage, bevor WordPress startet, das spart Serverressourcen. Ein Plugin ist einfacher zu installieren und erfordert keine Dateibearbeitung. Für nicht kritische Websites gibt es kaum einen Unterschied. Für stark frequentierte Projekte ist .htaccess oder eine WAF-Regel vorzuziehen.

Muss ich WordPress nach der Deaktivierung von xmlrpc.php aktualisieren?

Nein. Die Deaktivierung von xmlrpc.php hängt nicht von der WordPress-Version ab und beeinflusst keine Core-Updates. Die einzige Nuance: Wenn Sie die Datei physisch gelöscht haben, stellt das Update sie wieder her, was eine erneute Löschung erfordert.

Was sollten Sie also mit xmlrpc.php auf Ihrer Website tun?

Es gibt keine universelle Antwort, der Kontext entscheidet alles. Aber die Praxis tausender WordPress-Seiten ergibt ein klares Bild: Wenn Sie nicht wissen, ob Sie XML-RPC benötigen, benötigen Sie es nicht.

Wollen Sie Zuverlässigkeit, ohne in Code einzutauchen, installieren Sie Disable XML-RPC. Sind Sie bereit, fünf Minuten in .htaccess zu investieren, erhalten Sie Schutz auf Serverebene ohne zusätzliche Plugins. Nutzen Sie Cloudflare, richten Sie eine WAF-Regel ein und vergessen Sie das Problem.

Die Hauptsache ist, xmlrpc.php nicht „standardmäßig" offen zu lassen. Im Jahr 2026 ist jeder ungeschützte WordPress-Endpunkt ein Ziel für automatisierte Bots, denen es egal ist, ob Sie einen Blog oder einen Online-Shop betreiben. Sperren Sie den Zugriff mit einer der oben genannten Methoden, prüfen Sie das Ergebnis mit einer curl-Anfrage und schlafen Sie ruhig.