← Zurück zum Glossar
webentwicklung

XML-RPC

Veraltetes Remote-Procedure-Call-Protokoll über HTTP mit XML-Encoding — in WordPress ein bekanntes Angriffsziel.

Aktualisiert: 23. Februar 2026

Was ist XML-RPC?

XML-RPC (XML Remote Procedure Call) ist ein Protokoll, das entfernte Funktionsaufrufe über HTTP mit XML als Datenformat ermöglicht. Es wurde 1998 von Dave Winer und Microsoft entwickelt und war ein Vorläufer von SOAP und REST-APIs. In WordPress ist XML-RPC über die Datei xmlrpc.php seit Version 1.5 (2005) integriert — und bis heute eine der häufigsten Angriffsflächen für Brute-Force- und DDoS-Attacken.

Für den normalen WordPress-Betrieb braucht heutzutage kaum noch jemand XML-RPC. Die REST API hat alle relevanten Funktionen übernommen. Dennoch ist xmlrpc.php standardmäßig aktiv und erreichbar — was es zu einem bevorzugten Ziel für automatisierte Angriffe macht.

Kurzprofil XML-RPC

Kurzprofil

  • Typ: Remote-Procedure-Call-Protokoll
  • Eingeführt: 1998 (Spezifikation), WordPress: 2005 (v1.5)
  • Spezifikation: xmlrpc.com
  • Status: Legacy — von REST APIs weitgehend abgelöst
  • Relevanz für WordPress/Web: Hoch (Sicherheitsaspekt)

Wie funktioniert XML-RPC?

Ein XML-RPC-Aufruf ist eine HTTP-POST-Anfrage an einen Endpunkt (in WordPress: /xmlrpc.php). Im Body steht ein XML-Dokument, das Methode und Parameter beschreibt. Der Server antwortet ebenfalls mit XML.

Ein Beispiel-Request zum Abrufen von WordPress-Posts:

<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getPosts</methodName>
  <params>
    <param><value><int>1</int></value></param>       <!-- Blog-ID -->
    <param><value><string>admin</string></value></param>  <!-- Benutzername -->
    <param><value><string>passwort</string></value></param> <!-- Passwort -->
  </params>
</methodCall>

Das Problem wird im Beispiel sofort sichtbar: Credentials werden im Klartext übertragen (vorausgesetzt kein HTTPS) und bei jeder Anfrage erneut mitgesendet — ohne Session-Token oder moderne Authentifizierungsmechanismen.

WordPress implementiert über xmlrpc.php zahlreiche Methoden: wp.newPost, wp.editPost, wp.uploadFile, system.multicall (mehrere Aufrufe in einem Request). Letztere ist besonders gefährlich: Sie erlaubt hunderte Login-Versuche in einem einzigen HTTP-Request, was klassische Rate-Limiting-Mechanismen umgeht.

XML-RPC in der Praxis

Die meisten WordPress-Sicherheitsscanner melden xmlrpc.php als Risiko, wenn die Datei öffentlich erreichbar ist. Angreifer nutzen sie für:

Brute-Force über multicall: Mit system.multicall können in einem einzigen Request Hunderte Passwort-Kombinationen getestet werden. Selbst aggressive Rate-Limits (z.B. 5 Requests/Minute) schützen nicht, wenn jeder Request 200 Login-Versuche enthält.

DDoS-Amplification: xmlrpc.php kann als Reflector missbraucht werden, indem viele Pingbacks von kompromittierten WordPress-Sites auf ein Ziel umgeleitet werden.

Deaktivierung über .htaccess (Apache) oder Nginx-Konfiguration ist die sicherste Option:

# Nginx
location = /xmlrpc.php {
    deny all;
}

# Apache .htaccess
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Alternativ per WordPress-Filter (für Plugins, die XML-RPC noch benötigen):

add_filter('xmlrpc_enabled', '__return_false');
Auf einen Blick

Das Wichtigste

  • XML-RPC ist ein veraltetes RPC-Protokoll über HTTP mit XML-Encoding
  • In WordPress über /xmlrpc.php erreichbar — standardmäßig aktiv
  • system.multicall ermöglicht hunderte Login-Versuche pro Request (Brute-Force-Risiko)
  • Für moderne WordPress-Installationen empfiehlt sich die Deaktivierung
  • Ersetzt durch die WordPress REST API (/wp-json/)

Was passiert wenn XML-RPC aktiv bleibt?

Ein aktives xmlrpc.php führt in der Regel zu permanentem Scan-Traffic in den Server-Logs. Auf stark frequentierten Websites verursachen Brute-Force-Attacken über XML-RPC messbaren CPU- und Datenbankload. Manche Hosting-Anbieter sperren WordPress-Installationen automatisch, wenn xmlrpc.php exzessiv angegriffen wird.

Auch ohne erfolgreichen Angriff bedeutet jede XML-RPC-Anfrage eine vollständige WordPress-Bootstrap-Sequenz — inklusive Datenbankverbindung und Plugin-Initialisierung. Bei volumetrischen Angriffen reicht das für effektiven Denial of Service.

Häufige Fragen

Brauchen noch irgendwelche Tools XML-RPC? Wenige. Ältere mobile WordPress-Apps und Desktop-Clients wie MarsEdit nutzten XML-RPC. Moderne Tools verwenden die REST API. Prüfen lässt sich das mit: grep -r "xmlrpc" ~/.app/config oder dem Deaktivieren für 24h mit Monitoring der Fehler-Logs.

Schützt ein XML-RPC-Passwort-Filter wirklich? Nur bedingt. Wer nur bestimmten IPs Zugriff erlaubt oder xmlrpc.php auf Netzwerkebene blockiert (Firewall, Webserver), schützt sich zuverlässiger als mit WordPress-internen Filtern — die erst nach dem WordPress-Bootstrap greifen.

Ist XML-RPC in WordPress noch nötig für Jetpack? Jetpack hat in neueren Versionen auf die REST API und OAuth umgestellt. XML-RPC wird von Jetpack nicht mehr zwingend benötigt.

Verwandte Begriffe

PHP · REST API

start call_