Wie man xmlrpc.php in WordPress aktiviert und deaktiviert (und warum es wichtig ist)

Die xmlrpc.php-Datei ist eine zentrale WordPress-Komponente, die einen XML-RPC-API-Endpunkt bereitstellt und es Remote-Anwendungen ermöglicht, sich zu authentifizieren und serverseitige Operationen auszuführen – Beiträge veröffentlichen, Kommentare verwalten, Pingbacks auslösen und mehr. Da sie standardmäßig nicht authentifizierte POST-Anfragen akzeptiert und diese verarbeitet, bevor die meisten Sicherheitsebenen aktiviert werden, ist sie eine der am häufigsten missbrauchten Angriffsflächen in jeder WordPress-Installation.

Wenn Sie die WordPress-Mobile-App, Jetpack oder einen Drittanbieterdienst, der explizit XML-RPC erfordert, nicht verwenden, ist die Deaktivierung von xmlrpc.php die richtige Standard-Sicherheitshaltung. Wenn Sie auf diese Integrationen angewiesen sind, können Sie den Endpunkt absichern, anstatt ihn vollständig zu entfernen.

Was ist xmlrpc.php und wie funktioniert es

XML-RPC (Extensible Markup Language Remote Procedure Call) ist ein Protokoll, das Funktionsaufrufe in XML kodiert und über HTTP überträgt. WordPress wird seit Version 3.5 mit einem vollständigen XML-RPC-Server ausgeliefert, der in der Datei xmlrpc.php im WordPress-Stammverzeichnis implementiert ist.

Wenn ein Remote-Client – eine Mobile-App, ein Desktop-Blogging-Client oder ein Automatisierungsskript – eine POST-Anfrage an https://yourdomain.com/xmlrpc.php sendet, analysiert WordPress die XML-Nutzlast, authentifiziert die im Anfragekörper eingebetteten Anmeldedaten und führt die angeforderte Methode aus. Der gesamte Austausch findet in einem einzigen HTTP-Roundtrip statt, was sowohl seine Stärke als auch seine grundlegende Schwäche aus Sicherheitsperspektive ist.

Von WordPress bereitgestellte XML-RPC-Kernmethoden

• wp.newPost / wp.editPost — Beiträge remote erstellen und aktualisieren
• wp.getComments / wp.deleteComment — Kommentare verwalten
• wp.uploadFile — Medien auf den Server hochladen
• pingback.ping — eine Remote-Website benachrichtigen, dass sie verlinkt wurde
• system.multicall — mehrere Methodenaufrufe in einer einzigen HTTP-Anfrage bündeln

Die system.multicall-Methode ist besonders gefährlich. Eine einzige HTTP-Anfrage kann Hunderte von wp.getUsersBlogs-Aufrufen bündeln, von denen jeder ein anderes Passwort testet. Dies ermöglicht es einem Angreifer, Tausende von Authentifizierungsversuchen durchzuführen, während nur ein einziger Server-Log-Eintrag generiert wird, wodurch Rate-Limiting-Tools, die einzelne Anfragen zählen, umgangen werden.

Sicherheitsrisiken bei aktiviertem xmlrpc.php

Brute-Force-Amplifikation über system.multicall

Herkömmliche Brute-Force-Angriffe senden ein Anmeldedatenpaar pro HTTP-Anfrage. Mit XML-RPC verpackt ein Angreifer 500 Anmeldeversuche in einer einzigen system.multicall-Nutzlast. Eine Standard-fail2ban-Regel oder ein Anmeldeversuchszähler sieht eine Anfrage; der Angreifer erhält 500 Versuche. Dies ist kein theoretisches Risiko – es ist der am häufigsten in der Praxis beobachtete XML-RPC-Exploit.

Pingback-verstärkter DDoS

WordPress verarbeitet eingehende Pingback-Anfragen automatisch über xmlrpc.php. Ein Angreifer kann eine manipulierte pingback.ping-Anfrage an Tausende von WordPress-Seiten senden und jede anweisen, eine HTTP-Anfrage an eine einzelne Opfer-URL zu senden. Das Opfer erhält eine volumetrische Flut von Anfragen, die von legitimen WordPress-Servern stammen, was IP-basiertes Blockieren unwirksam macht. Ihr Server wird gleichzeitig zum Opfer (Ressourcenerschöpfung) und zu einem unfreiwilligen Angriffsverstärker.

SSRF über Pingback

Der Pingback-Mechanismus kann für Server-Side Request Forgery (SSRF) missbraucht werden. Ein Angreifer sendet eine pingback.ping-Anfrage, bei der die Quell-URL auf eine interne Netzwerkressource zeigt – beispielsweise http://192.168.1.1/admin. Der WordPress-Server ruft diese URL von innerhalb des Netzwerkperimeters ab und legt dabei möglicherweise interne Dienste frei, die nicht öffentlich routbar sind.

Anmeldedaten-Exposition während der Übertragung

XML-RPC überträgt Anmeldedaten im POST-Body als Klartext innerhalb des XML-Envelopes. Wenn Ihre Website kein HTTPS erzwingt, sind Anmeldedaten für jeden Netzwerkbeobachter sichtbar. Selbst mit TLS sind die Anmeldedaten in jede einzelne Anfrage eingebettet – es gibt kein Sitzungstoken oder OAuth-Flow, um das Expositionsfenster zu begrenzen.

Wann Sie xmlrpc.php aktiviert lassen sollten

Deaktivieren Sie es standardmäßig, aber lassen Sie es aktiviert, wenn Ihr Workflow tatsächlich von einem der folgenden abhängt:

• WordPress-Mobile-App (iOS/Android): Die offizielle App verwendet XML-RPC für alle Website-Verwaltungsoperationen auf selbst gehosteten WordPress-Installationen.
• Jetpack-Plugin: Mehrere Jetpack-Module – darunter Publicize, mobile Push-Benachrichtigungen und einige Statistikfunktionen – kommunizieren über XML-RPC mit WordPress.com-Servern.
• Desktop-Blogging-Clients: MarsEdit, Windows Live Writer und ähnliche Tools sind ausschließlich auf die XML-RPC-API angewiesen.
• Automatisierte Publishing-Pipelines: IFTTT, Zapier und benutzerdefinierte Skripte, die Inhalte an WordPress übertragen, verwenden häufig XML-RPC, wenn die REST API nicht konfiguriert ist.
• Pingbacks/Trackbacks zwischen WordPress-Seiten: Wenn seitenübergreifende Pingback-Benachrichtigungen Teil Ihres redaktionellen Workflows sind, deaktiviert das Deaktivieren von xmlrpc.php diese.

Wenn keines davon zutrifft, gibt es keinen betrieblichen Grund, den Endpunkt offen zu lassen.

xmlrpc.php vs. die WordPress REST API

WordPress führte die REST API in Version 4.7 als modernen, tokenbasierten Ersatz für XML-RPC ein. Das Verständnis der Unterschiede hilft Ihnen zu entscheiden, ob die Deaktivierung von XML-RPC etwas Kritisches beeinträchtigt.

Wenn Sie eine neue Integration erstellen oder eine bestehende migrieren, verwenden Sie die REST API. Das Authentifizierungsmodell ist deutlich sicherer, und der Endpunkt ist auf Infrastrukturebene wesentlich einfacher zu prüfen und zu rate-limitieren.

So deaktivieren Sie xmlrpc.php in WordPress

Wählen Sie die Methode, die Ihrem Server-Zugriffsniveau und Ihrer Risikobereitschaft entspricht. Die Methoden sind von der niedrigsten zur höchsten Durchsetzung auf Serverebene geordnet.

Methode 1: Deaktivierung über Plugin (Schnellste Methode, kein Server-Zugriff erforderlich)

Für Shared-Hosting-Umgebungen oder Websites, bei denen Sie Server-Konfigurationsdateien lieber nicht bearbeiten möchten, ist ein Plugin die zugänglichste Option.

Empfohlene Plugins:

• Disable XML-RPC-API — zweckgebunden, minimaler Footprint, wird sofort aktiviert
• All In One WP Security and Firewall — umfassendere Sicherheitssuite mit granularen XML-RPC-Kontrollen

Schritte für Disable XML-RPC-API:

1. Navigieren Sie in Ihrem WordPress-Dashboard zu Plugins > Neu hinzufügen.
2. Suchen Sie nach „Disable XML-RPC-API” und klicken Sie auf Jetzt installieren, dann auf Aktivieren.
3. Es ist keine weitere Konfiguration erforderlich – das Plugin hängt sich in xmlrpc_enabled ein und gibt bei der Aktivierung sofort false zurück.

Schritte für All In One WP Security and Firewall:

1. Gehen Sie nach der Aktivierung des Plugins zu WP Security > Firewall.
2. Suchen Sie den Abschnitt XML-RPC.
3. Aktivieren Sie die Option, XML-RPC-Anfragen vollständig zu blockieren.
4. Einstellungen speichern.

Einschränkung: Plugin-basiertes Blockieren wird innerhalb des WordPress-PHP-Ausführungskontexts ausgelöst. Der Server startet PHP noch, lädt WordPress und verarbeitet die Anfrage, bevor sie abgelehnt wird. Bei einem schweren Angriff verbraucht dies CPU und Arbeitsspeicher. Für stark frequentierte Websites unter aktivem Angriff verwenden Sie stattdessen die .htaccess– oder Nginx-Methode.

Methode 2: Deaktivierung über .htaccess (Apache — Blockierung auf Serverebene)

Das Blockieren auf .htaccess-Ebene verhindert, dass PHP für Anfragen, die auf xmlrpc.php abzielen, überhaupt ausgeführt wird. Dies ist unter Last deutlich effizienter.

1. Verbinden Sie sich über FTP, SFTP oder Ihren Hosting-Dateimanager mit Ihrem Server und öffnen Sie die .htaccess-Datei in Ihrem WordPress-Stammverzeichnis (typischerweise public_html/.htaccess).
2. Fügen Sie den folgenden Block hinzu. Platzieren Sie ihn vor den Standard-WordPress-Rewrite-Regeln:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Speichern Sie die Datei.

Um zu überprüfen, ob die Blockierung aktiv ist, führen Sie einen Test von Ihrem lokalen Rechner aus:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Sie sollten eine 403-Antwort erhalten. Eine 200 oder 405 bedeutet, dass die Blockierung noch nicht in Kraft ist.

Sonderfall – wenn Sie noch Pingbacks von bestimmten vertrauenswürdigen IPs benötigen, können Sie diese auf die Whitelist setzen:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Methode 3: Deaktivierung über Nginx-Konfiguration

Wenn Ihr Server Nginx betreibt (üblich in VPS-Hosting-Umgebungen), haben .htaccess-Dateien keine Wirkung. Fügen Sie den Block direkt zur Server-Block-Konfiguration Ihrer Website hinzu.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

Die return 444-Direktive schließt die TCP-Verbindung, ohne eine HTTP-Antwort zu senden, was effizienter als ein 403 ist, da es verhindert, dass der Client des Angreifers irgendein Feedback erhält. Laden Sie nach der Bearbeitung Nginx neu:

sudo nginx -t && sudo systemctl reload nginx

Platzieren Sie diesen location-Block innerhalb Ihres server {}-Blocks, vor allen try_files– oder PHP-Verarbeitungsdirektiven.

Methode 4: Deaktivierung über functions.php (WordPress-Filter-Hook)

Diese Methode verwendet einen WordPress-Filter, um XML-RPC auf der Anwendungsebene zu deaktivieren. Sie ist weniger effizient als die Blockierung auf Serverebene, aber nützlich, wenn Sie keinen direkten Server-Zugriff haben und eine codebasierte Lösung ohne Plugin-Abhängigkeit wünschen.

1. Gehen Sie in Ihrem WordPress-Dashboard zu Design > Theme-Editor oder greifen Sie direkt über SFTP auf die Datei unter wp-content/themes/your-theme/functions.php zu.
2. Fügen Sie am Ende der Datei Folgendes hinzu:

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

1. Speichern Sie die Datei.

Wichtiger Vorbehalt: Dieser Filter deaktiviert authentifizierte XML-RPC-Methoden, blockiert jedoch nicht die pingback.ping-Methode und verhindert nicht den Zugriff auf die Datei. Der Server verarbeitet die Anfrage noch bis zu dem Punkt, an dem WordPress den Filter auswertet. Für vollständigen Schutz kombinieren Sie dies mit dem .htaccess– oder Nginx-Block.

Wenn Sie ein Child-Theme verwenden, fügen Sie benutzerdefinierten Code immer zur functions.php des Child-Themes hinzu, nicht zum Parent-Theme. Parent-Theme-Updates überschreiben Ihre Änderungen.

Methode 5: Selektive Deaktivierung — Nur Pingbacks blockieren

Wenn Sie XML-RPC für Jetpack oder mobiles Publishing benötigen, aber den DDoS-Amplifikationsvektor eliminieren möchten, können Sie nur die Pingback-Methode deaktivieren und den Rest der API funktionsfähig lassen.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Fügen Sie dies zur functions.php Ihres Child-Themes oder einem seitenspezifischen Plugin hinzu. Dies ist die empfohlene Konfiguration für Websites, die Jetpack betreiben, aber keine Pingbacks empfangen müssen.

So aktivieren Sie xmlrpc.php wieder

Das Rückgängigmachen einer der oben genannten Methoden stellt den XML-RPC-Zugriff wieder her:

• Plugin-Methode: Deaktivieren oder löschen Sie das Blockierungs-Plugin unter Plugins > Installierte Plugins.
• .htaccess-Methode: Entfernen Sie den <Files "xmlrpc.php">-Block aus .htaccess und speichern Sie.
• Nginx-Methode: Entfernen Sie den location = /xmlrpc.php-Block aus Ihrer Server-Konfiguration und laden Sie Nginx mit sudo systemctl reload nginx neu.
• functions.php-Methode: Entfernen Sie die add_filter( 'xmlrpc_enabled', '__return_false' )-Zeile und speichern Sie.

Überprüfen Sie nach der Reaktivierung, ob der Endpunkt korrekt antwortet:

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Eine gültige XML-Antwort, die verfügbare Methoden auflistet, bestätigt, dass der Endpunkt aktiv ist.

xmlrpc.php absichern ohne es zu deaktivieren

Wenn eine Deaktivierung keine Option ist, wenden Sie diese Maßnahmen an, um die Angriffsfläche zu reduzieren:

HTTPS erzwingen: Stellen Sie sicher, dass Ihre Website ein gültiges TLS-Zertifikat verwendet. Falls noch nicht geschehen, konfigurieren Sie eines über Ihren Hosting-Anbieter – SSL-Zertifikate verhindern das Abfangen von Anmeldedaten während der Übertragung.

Rate-Limiting auf Firewall- oder CDN-Ebene: Konfigurieren Sie Ihre WAF (Cloudflare, ModSecurity), um POST-Anfragen an xmlrpc.php auf maximal 5–10 pro Minute pro IP zu begrenzen.

system.multicall gezielt blockieren:

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

Dies eliminiert den Brute-Force-Amplifikationsvektor, während alle anderen XML-RPC-Funktionen erhalten bleiben.

Nach IP einschränken: Wenn Sie nur von bekannten IP-Adressen auf XML-RPC zugreifen (dem Carrier-IP-Bereich Ihrer Mobile-App oder einer statischen Büro-IP), setzen Sie diese Adressen in .htaccess oder Nginx auf die Whitelist und verweigern Sie allen anderen den Zugriff.

Zugriffsprotokolle überwachen: Prüfen Sie regelmäßig Ihre Server-Logs auf wiederholte POST-Anfragen an xmlrpc.php. Ein Anstieg von POST-Anfragen mit Status 200 an diese Datei ist ein zuverlässiger Indikator für eine laufende Brute-Force-Kampagne.

Auf einem VPS mit cPanel oder einer anderen verwalteten Panel-Umgebung können Sie ModSecurity-Regeln direkt über das Control Panel konfigurieren, um diese Einschränkungen ohne manuelle Dateibearbeitung durchzusetzen.

Die richtige Methode wählen: Entscheidungsmatrix

Für Produktions-Websites, die auf Dedicated Servern gehostet werden, ist der Nginx- oder Apache-Block auf Serverebene einer Plugin-basierten Lösung immer vorzuziehen, da er die PHP-Ausführung für bösartige Anfragen vollständig verhindert und den CPU-Overhead eliminiert, den Plugin-basiertes Blockieren bei anhaltenden Angriffen verursacht.

Praktische Checkliste der wichtigsten Erkenntnisse

• Prüfen Sie, ob ein aktives Plugin oder ein Dienst in Ihrem Stack tatsächlich XML-RPC benötigt, bevor Sie es deaktivieren – überprüfen Sie Jetpack, Mobile-Apps und alle Publishing-Automatisierungstools.
• Wenn keine Abhängigkeit besteht, wenden Sie den Block auf Serverebene (.htaccess oder Nginx) anstatt eines Plugins an – er ist effizienter und übersteht die Deaktivierung von Plugins.
• Wenn Sie XML-RPC aktiv lassen müssen, entfernen Sie system.multicall und pingback.ping bedingungslos über den xmlrpc_methods-Filter – diese beiden Methoden sind für die große Mehrheit des XML-RPC-Missbrauchs verantwortlich.
• Erzwingen Sie immer HTTPS auf jeder WordPress-Website, die authentifizierte Anfragen akzeptiert, einschließlich XML-RPC.
• Überprüfen Sie nach dem Anwenden eines Blocks mit curl, dass der Endpunkt 403 zurückgibt oder die Verbindung abbricht – gehen Sie nicht davon aus, dass die Konfiguration korrekt ist, ohne sie zu testen.
• Verwenden Sie in Nginx-basierten VPS- oder Dedicated-Server-Umgebungen return 444 anstatt deny all, um Angreifern kein HTTP-Level-Feedback zu geben.
• Protokollieren und überwachen Sie POST-Anfragen an xmlrpc.php – ein plötzlicher Anstieg ist ein frühes Warnsignal für eine Credential-Stuffing- oder DDoS-Amplifikationskampagne.
• Wenn Sie mehrere WordPress-Websites verwalten, erwägen Sie, diese Konfiguration auf Server- oder CDN-Ebene zu zentralisieren, anstatt Pro-Website-Plugin-Regeln anzuwenden.

Für Websites, die eine robuste Remote-Verwaltung ohne die XML-RPC-Risikooberfläche benötigen, ist die Migration von Integrationen zur WordPress REST API mit Anwendungspasswörtern der richtige langfristige Weg. Die REST API bietet Pro-Token-Widerruf, begrenzte Berechtigungen und Standard-HTTP-Semantik, die wesentlich einfacher zu sichern und zu prüfen sind.

Wenn Sie eine neue WordPress-Umgebung einrichten und von Anfang an eine saubere, sichere Basis wünschen, bieten VPS-Control-Panels mit vorkonfiguriertem ModSecurity WAF-Schutz auf Serverebene, ohne dass manuelle Regelerstellung erforderlich ist.

—

Häufig gestellte Fragen

Beeinträchtigt die Deaktivierung von xmlrpc.php die WordPress REST API?

Nein. Die REST API (/wp-json/) ist ein völlig separater Endpunkt mit eigener Authentifizierung und eigenem Routing. Das Blockieren von xmlrpc.php hat keinerlei Auswirkungen auf die REST-API-Funktionalität. Die beiden Systeme sind architektonisch unabhängig.

Beeinträchtigt die Deaktivierung von xmlrpc.php Jetpack?

Das hängt davon ab, welche Jetpack-Module Sie verwenden. Jetpack hat Funktionen schrittweise zur REST API migriert, aber einige ältere Module – darunter bestimmte Publicize- und Benachrichtigungsfunktionen – kommunizieren noch über XML-RPC. Überprüfen Sie die Jetpack-Debug-Seite unter Jetpack > Dashboard > Debug, um zu sehen, ob XML-RPC-Konnektivität als Anforderung aufgeführt ist, bevor Sie es deaktivieren.

Ist die .htaccess-Methode oder die functions.php-Methode sicherer?

Die .htaccess-Methode ist unter Angriffsbedingungen deutlich sicherer. Sie blockiert die Anfrage auf der Webserver-Ebene, bevor PHP geladen wird, und verbraucht dabei minimale Ressourcen. Der functions.php-Filter wird innerhalb des PHP-Ausführungskontexts von WordPress ausgelöst, was bedeutet, dass der Server WordPress für jede blockierte Anfrage noch hochfährt – was bei einem hochvolumigen Angriff kostspielig ist.

Kann ein Angreifer xmlrpc.php noch ausnutzen, wenn ich es nur über den WordPress-Filter deaktiviere?

Teilweise. Der xmlrpc_enabled-Filter verhindert authentifizierte Methodenaufrufe, aber die Datei bleibt öffentlich zugänglich und der Server verarbeitet eingehende Anfragen noch. Der Pingback-Endpunkt kann je nach WordPress-Version teilweise funktionsfähig bleiben. Für vollständigen Schutz kombinieren Sie den Filter mit einem Block auf Serverebene.

Wie überprüfe ich, ob xmlrpc.php auf meiner Website derzeit zugänglich ist?

Führen Sie den folgenden Befehl von Ihrem lokalen Terminal aus und ersetzen Sie die Domain durch Ihre eigene:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Eine 200-Antwort bedeutet, dass der Endpunkt offen ist. Eine 403 oder ein Verbindungsabbruch (000) bestätigt, dass er blockiert ist. Sie können auch das Online-Tool unter xmlrpc.eritreo.it verwenden, um speziell die Pingback-Schwachstelle zu testen.