XML-RPC deaktivieren in WordPress: Brute-Force-Schutz auf 3 Ebenen (2026).

Im Frühjahr 2026 gingen laut Wordfence-Quarterly-Report 41 % aller Brute-Force-Versuche gegen WordPress-Sites über xmlrpc.php — nicht über wp-login.php. Der Grund ist simpel: ein einziger POST mit system.multicall kann bis zu 1.000 Login-Versuche in einem Request bündeln. Brute-Force-Throttling auf Login-Page-Ebene? Wirkungslos.

Wenn du also Wordfence, Limit Login Attempts oder Sucuri installiert hast und denkst „mein WordPress ist gegen Brute-Force geschützt" — du täuschst dich. Diese Plugins zählen Login-Versuche pro Request, nicht pro Multicall-Payload. Sie blocken die wp-login.php-Versuche, aber an xmlrpc.php hängen sie sich erst NACH dem WordPress-Bootstrap dran. Dein Hoster bezahlt die CPU-Rechnung trotzdem.

Dieser Post zeigt dir den dreischichtigen Defense-in-Depth-Ansatz, der wirklich greift: Server-Level vor PHP, App-Level im Filter, plus REST-API-Hardening gegen User-Enumeration. In 8 Minuten installiert, ohne Plugin, ohne Maintenance-Aufwand.

TL;DR — XML-RPC in 8 Minuten sicher schließen

1. Server-Level (Schicht 1): 4 Zeilen in der .htaccess (Apache) oder nginx.conf, die xmlrpc.php-Requests verwerfen, BEVOR PHP startet. Null CPU-Last bei Brute-Force-Wellen.
2. App-Level (Schicht 2): PHP-Snippet aus der Smart-Fix-Library — deaktiviert die Filter, entfernt Pingback-Methoden, schützt User-Enumeration.
3. Auto-Safety-Check (Bonus): das Snippet erkennt aktives Jetpack/Wordfence/Sucuri und greift dann nicht ein — du musst dich nicht zwischen Security-Plugin und xmlrpc-Hardening entscheiden.

Erwartete Wirkung: Brute-Force-Angriffe über xmlrpc.php werden bereits auf Web-Server-Ebene verworfen. Null CPU-Last, null DB-Queries, null Bootstrap-Kosten.

XML-RPC-Hardening-Snippet im Code-Lab öffnen →

---

Was XML-RPC ist und warum es heute ein Angriffsmagnet ist

XML-RPC ist ein Remote-Procedure-Call-Protokoll, das seit WordPress 2.6 (2008) im Core mitgeliefert wird. Ursprünglich für Remote-Publishing gedacht: du schreibst einen Artikel in einer Desktop-App (damals: MarsEdit, Windows Live Writer), und sie pusht den Beitrag per XML-RPC ins WordPress. Plus Trackbacks und Pingbacks zwischen Blogs.

2026 ist diese Architektur eine Sicherheits-Antiquität. Drei Gründe:

1. system.multicall ist Brute-Force-Beschleuniger. Diese eine XML-RPC-Methode erlaubt, mehrere Calls in einem HTTP-Request zu bündeln. Angreifer nutzen das, um in einem POST 1.000 Username/Passwort-Kombinationen durchzuprobieren. Klassisches Login-Throttling, das auf „X failed logins per minute per IP" basiert, sieht nur EINEN Request und blockt nicht.

2. Kein Captcha, kein 2FA, kein Rate-Limiting im Default. Die XML-RPC-Schnittstelle hat keine native Anti-Bot-Schicht. Während wp-login.php seit Jahren von hunderten Plugins gehärtet wird (Two-Factor-Auth, Captcha, Honeypot etc.), bleibt xmlrpc.php das untergeschmiedete Hinterzimmer.

3. Die wenigsten Sites nutzen XML-RPC noch aktiv. Mit WordPress 5.6 (Dezember 2020) wurde Application-Passwords als modernerer Auth-Pfad eingeführt. Die offizielle Mobile-App, fast alle Headless-CMS-Integrationen und die meisten Publishing-Tools nutzen heute REST-API oder Application-Passwords. XML-RPC ist für 80–90 % der Sites Dead Weight mit aktiver Angriffsfläche.

Cloudflare-Daten Q4 2025: in den ausgewerteten 12 Mio. WordPress-Sites auf Cloudflare-DNS gingen ~37 % aller verworfenen Login-Requests an /xmlrpc.php. Bei Sites unter 10k Monthly Visitors war der Anteil sogar bei 52 % — kleine Sites werden disproportional getroffen, weil sie keine teuren Security-Plugins kaufen.

---

Symptome auf deiner Site

Wenn drei dieser Indikatoren bei dir zutreffen, läuft mit hoher Wahrscheinlichkeit eine XML-RPC-Brute-Force-Welle:

• Plötzliche CPU-Spitzen ohne entsprechenden Frontend-Traffic. Du siehst im Hosting-Panel oder via top einen anhaltend hohen PHP-Worker-Verbrauch, obwohl der Frontend-Traffic flach ist.
• Access-Log voller POST /xmlrpc.php-Einträge, IPs bunt gemischt aus DE/RU/CN/US — verteilte Botnets, nicht einzelne Angreifer.
• Wordfence- oder Sucuri-Dashboard zeigt XML-RPC-Blocks im vierstelligen Bereich pro Tag. Du denkst „gut, wird ja geblockt" — siehe Sektion zum Wordfence-Trick weiter unten, das ist trügerisch.
• Hoster-Warn-Mails mit Betreff „erhöhter Ressourcen-Verbrauch", „CPU-Limit überschritten" oder „IO-Operationen erhöht". Vor allem Strato und IONOS verschicken die routinemäßig.
• HEAD-Test gibt 200 OK statt 403/404: curl -I https://deine-site.de/xmlrpc.php. Bei aktivem XML-RPC bekommst du Status 405 (Method Not Allowed) oder 200 — beides Hinweis, dass die Datei vom Server angenommen + von PHP geladen wird.

Wenn keines davon zutrifft, betreibst du wahrscheinlich eine Hochsicherheits-Site oder einen Hoster mit gutem Edge-Filtering. Wenn mehrere zutreffen: weiterlesen, das ist genau dein Schmerzpunkt.

---

Der Wordfence-Trick: warum „blocken" oft nicht reicht

Hier ist die unbequeme Wahrheit, die kaum ein Security-Plugin-Tutorial offen ausspricht: Wordfence, Sucuri und iThemes Security blockieren XML-RPC technisch zu spät.

So sieht der Bootstrap-Pfad eines WordPress-Requests aus, wenn jemand POST /xmlrpc.php mit einem brute-force-Login-Payload an deinen Server schickt:

Apache/nginx empfängt Request
         ↓
PHP-FPM startet Worker-Prozess
         ↓
WordPress wp-load.php (loaded)
         ↓
wp-settings.php (Plugin-Loader)
         ↓
Aktive Plugins werden initialisiert (inkl. Wordfence)
         ↓
Theme wird geladen + functions.php
         ↓
Authentication-Check (Cookies, Headers)
         ↓
xmlrpc.php-Endpoint-Logik beginnt
         ↓
apply_filters( 'xmlrpc_enabled', true ) — JETZT erst checkt Wordfence
         ↓
"disabled" → Response zurück

Bis zum Filter-Check sind 80–200 ms CPU-Zeit verbraucht, je nach Plugin-Stack zwischen 4 und 12 DB-Queries gelaufen, und der Memory-Peak hat 16–48 MB belegt. Pro Request. Bei einer Brute-Force-Welle mit 10.000 Versuchen pro Tag ergibt das:

Kennzahl	Pro Tag
Verbrauchte CPU-Zeit (nur für abgewiesene XML-RPC-Calls)	~20–35 Minuten
Lese-Queries auf wp_options + wp_users	40.000–120.000
Memory-Peaks > 32 MB	~10.000

Dein Wordfence-Dashboard zeigt „10.000 Blocks heute" — und du denkst, du bist geschützt. Du bist es technisch auf Login-Ebene, aber dein Hoster verrechnet trotzdem die CPU-Last. Bei Shared-Hosting-Plänen mit hartem CPU-Quota landest du regelmäßig im 503-Timeout, obwohl deine eigentliche Site kaum Traffic hat.

Lösung: den Request schon auf Server-Level abweisen, bevor PHP überhaupt startet. Genau das macht Schicht 1.

---

Schicht 1: Server-Level-Block (Apache + nginx)

Die effektivste Verteidigung passiert vor dem WordPress-Bootstrap.

Apache (.htaccess) — Standard für IONOS, Strato, All-Inkl, webgo

Öffne die .htaccess im WordPress-Root (gleiche Ebene wie wp-config.php) und füge die folgenden Zeilen ein, am besten am Anfang:

# XML-RPC vor WordPress-Bootstrap blockieren
<Files xmlrpc.php>
    Require all denied
</Files>

Wirkung: Apache schickt sofort 403 Forbidden zurück, sobald die URL auf xmlrpc.php matched. WordPress wird nie geladen. Null PHP-Cost. Null DB-Query. Null Memory.

nginx (nginx.conf oder Site-Config) — für Hetzner, dedizierte Server, manche Managed-WordPress-Hoster

In deine Site-Config (typisch /etc/nginx/sites-available/deine-site.conf):

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

return 444 ist nginx-spezifisch und schließt die Verbindung ohne Response — Bots bekommen nicht mal ein Status-Code-Feedback, was sie konfusioniert und manche Brute-Force-Frameworks zum Rückzug bewegt. access_log off plus log_not_found off verhindern, dass dein Server-Log mit 10.000 Brute-Force-Zeilen pro Tag voll-läuft.

Was tun, wenn du keinen Server-Zugriff hast

Bei stark managed WordPress-Hostern (manche Strato-Tarife, Hostpoint, Webhostone) hast du eventuell keinen .htaccess-Zugriff und keinen nginx-Edit-Pfad. In dem Fall: App-Level-Block (Schicht 2) reicht als alleinige Verteidigung, du verschenkst aber den Bootstrap-Schutz. Optional: Cloudflare-DNS mit eigener Firewall-Regel auf /xmlrpc.php einrichten — Free-Plan reicht für eine simple Block-Regel.

---

Schicht 2: PHP-Snippet aus der Smart-Fix-Library

Die zweite Schicht greift, wenn (a) du kein Server-Level-Zugriff hast, (b) als Defense-in-Depth-Backup für den Fall, dass die .htaccess-Regel mal versehentlich gelöscht wird (passiert bei Theme-Migrationen häufiger als man denkt), und (c) für die Pingback-Funktionalität und User-Enumeration-Hardening, die auf Server-Level nicht abgedeckt sind.

Der vollständige Snippet — inklusive Auto-Safety-Check, Pingback-Header-Cleanup und REST-API-User-Enumeration-Schutz — liegt copy-paste-ready hier:

XML-RPC-Hardening-Snippet im Code-Lab öffnen →

Der Kern in zwei Filtern:

// XML-RPC vollständig deaktivieren
add_filter( 'xmlrpc_enabled', '__return_false' );

// Pingback-Methoden zusätzlich aus der xmlrpc-Methods-Liste werfen
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
}, 10, 1 );

Das ist Defense-in-Depth: selbst wenn ein Plugin den xmlrpc_enabled-Filter überschreibt, ist pingback.ping separat entfernt. Plus: ausgehende Pingbacks werden abgeschaltet (pre_option_default_pingback_flag → zero) und der X-Pingback-Header verschwindet aus den HTTP-Responses — Bots erkennen WordPress-Sites oft an diesem Header.

Der Killer-Vorteil gegenüber einem Plugin: der Snippet enthält einen Auto-Safety-Check, der die active_plugins-Liste auf konkurrierende Security-Plugins prüft. Wenn Jetpack, Wordfence oder Sucuri aktiv sind, bricht der Snippet mit return ab und schreibt nur einen WP_DEBUG-Log-Eintrag. Du läufst nie in eine Doppel-Konfiguration, die sich gegenseitig überschreibt.

Warum überhaupt ein Snippet statt eines Plugins? Drei Gründe: keine Update-Overhead (Plugin-Maintainer kann aufgeben, Snippet bleibt unverändert dein), kein zusätzlicher Plugin-Slot (ein weniger im wp-admin), und version-controlled im Child-Theme oder Code-Snippets-Plugin — bei Site-Migrationen wandert die Konfiguration automatisch mit.

---

Schicht 3: REST-API-Hardening gegen User-Enumeration

Das ist die Sektion, die in 9 von 10 XML-RPC-Härtungs-Anleitungen fehlt — und gleichzeitig der bequemste Brute-Force-Vorbereitungs-Trick für Angreifer.

WordPress' REST-API bietet seit Version 4.7 (Dezember 2016) den Endpunkt /wp-json/wp/v2/users. Bei Standard-Konfiguration listet er ALLE Benutzer der Site auf, ohne Authentifizierung. Was siehst du da? User-ID, Slug, Anzeige-Name — und bei manchen Konfigurationen sogar den username, mit dem der User sich einloggt.

Probiere es jetzt: curl https://deine-site.de/wp-json/wp/v2/users. Wenn JSON mit Usernames zurückkommt: Angreifer wissen, wen sie via xmlrpc.php knacken müssen. Sie brauchen nicht raten — der Username liegt offen.

Der Snippet aus der Library enthält dafür einen REST-Authentication-Filter:

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! is_user_logged_in() && ! empty( $_SERVER['REQUEST_URI'] )
         && false !== strpos( wp_unslash( $_SERVER['REQUEST_URI'] ), '/wp-json/wp/v2/users' ) ) {
        return new WP_Error( 'rest_not_logged_in', 'Anmeldung erforderlich.', array( 'status' => 401 ) );
    }
    return $result;
}, 10, 1 );

Wirkung: anonyme Anfragen auf /wp-json/wp/v2/users werden mit 401 abgewiesen. Angemeldete Admin-User können den Endpunkt weiterhin nutzen (Funktionalität bleibt für legitime Use-Cases erhalten). Test: curl https://deine-site.de/wp-json/wp/v2/users → sollte jetzt {"code":"rest_not_logged_in","message":"Anmeldung erforderlich.","data":{"status":401}} zurückgeben.

---

Wann XML-RPC LASSEN — die vier Ausnahmen

Vier Szenarien, in denen du XML-RPC NICHT deaktivieren solltest, oder zumindest sehr vorsichtig sein musst:

1. Jetpack aktiv. Jetpack kommuniziert mit WordPress.com über XML-RPC. Wenn du Jetpack für Stats, Backup, Akismet oder die Mobile-Sync nutzt: NICHT deaktivieren. Der Snippet aus der Library erkennt das automatisch und macht ein No-op. Solltest du Jetpack später wieder deinstallieren, greift der Filter beim nächsten Page-Load und xmlrpc.php ist dann auch ohne manuelles Eingreifen geschlossen.

2. WordPress-Mobile-App im Team-Einsatz mit Pre-5.6-Setup. Die offizielle App nutzt seit WP 5.6 (Dezember 2020) Application-Passwords statt XML-RPC. Wenn ihr aber ältere Custom-Apps oder Drittanbieter-Editoren (MarsEdit, BlogPress) im Einsatz habt: erst auf Application-Passwords migrieren, DANN xmlrpc.php schließen. Der Migrations-Pfad ist im WordPress-Profil-Bereich unter „Application-Passwords" sichtbar.

3. Marketing-Suites (Hootsuite, Buffer, IFTTT-Recipes). Manche Social-Publishing-Tools posten Beiträge via XML-RPC. Hootsuite + Buffer haben seit 2021 alternative REST-API-Pfade, aber alte IFTTT-Recipes hängen oft an XML-RPC fest. Bevor du blockst: in den Tool-Settings prüfen, welche API-Methode genutzt wird.

4. WordPress.com-Importer/-Exporter und Klone. Wenn du Sites von einer WordPress-Installation auf eine andere klonen willst und dabei den nativen Importer nutzt: temporär deaktiviert lassen, klonen, dann wieder aktivieren. Die meisten Backup-/Klone-Plugins (Duplicator, UpdraftPlus, Migrate Guru) nutzen aber ihre eigenen Protokolle und sind nicht betroffen.

---

Verifizieren: hast du es richtig gemacht?

Drei Tests, vom oberflächlichsten zum gründlichsten — gehe alle drei durch, bevor du das Setup als „fertig" abhakst.

Test 1 — Browser: https://deine-site.de/xmlrpc.php aufrufen.

• Bei korrekt gesetzter .htaccess: 403 Forbidden (Apache-Default-Error-Page) oder leere Response (nginx mit return 444).
• Bei nur App-Level-Block: 200 OK mit Body „XML-RPC services are disabled on this site".
• Bei aktivem XML-RPC: „XML-RPC server accepts POST requests only." (HTTP 405).

Test 2 — curl mit Header-Inspection:

curl -I https://deine-site.de/xmlrpc.php

• Erwarteter Status-Code: HTTP/1.1 403 Forbidden (Server-Level-Block aktiv).

Test 3 — Brute-Force-Simulation: Online-Tools wie WPScan prüfen die XML-RPC-Verfügbarkeit als Teil ihres Standard-Scans. Nach korrektem Server-Level-Block gibt's die Meldung „xmlrpc.php returns HTTP 403 — protected". Vor dem Setup steht da typisch „xmlrpc.php is accessible (HTTP 405)".

Plus REST-API-Test:

curl https://deine-site.de/wp-json/wp/v2/users

Erwartete Antwort nach Schicht 3:

{"code":"rest_not_logged_in","message":"Anmeldung erforderlich.","data":{"status":401}}

Falls da immer noch eine User-Liste mit Slug + display_name zurückkommt: Snippet wurde nicht geladen oder ein Plugin überschreibt den Filter.

---

Erweiterte Strategie für Agenturen

Für Sie als Agentur multipliziert sich der Effekt mit jeder Kundensite, die Sie betreuen. Beispiel-Rechnung für eine mittelgroße Agentur:

Kennzahl	Ohne Schutz	Mit Schicht 1+2+3
Kundensites	30	30
XML-RPC-Brute-Force-Versuche pro Site pro Tag (ø)	5.000	5.000 (weiterhin Bot-Traffic)
CPU-Zeit pro abgewiesenem Versuch (App-Level)	~100 ms	~1 ms (Server-Level)
Tägliche CPU-Last allein durch XML-RPC	~75 Minuten	<1 Minute
503-Errors auf Kundensites / Monat (ø)	12–20	0–1
Hoster-Eskalations-Mails / Monat (ø)	2–4	0

Bulk-Rollout-Empfehlung:

1. MU-Plugin auf zentral verwalteter Site-Foundation ablegen, das für alle Kundensites identisch ist. Der WebsiteFix One-Click Optimizer macht genau das: schreibt den Snippet als mu-plugin ins /wp-content/mu-plugins/-Verzeichnis und greift damit netzwerk-weit ohne Theme-Edit.
2. .htaccess-Template für die Foundation, das beim Site-Setup ausgerollt wird (Ansible, WP-CLI-Script, oder manuell beim Bereitstellen).
3. Monitoring: in der WebsiteFix-Agency-Konsole sehen Sie pro Kundensite, ob xmlrpc.php noch erreichbar ist plus die täglichen Brute-Force-Versuche — als ein einziges Dashboard-Widget.

---

Weiterführend

Drei thematisch passende Anschluss-Lektüren, wenn dieser Post deinen XML-RPC-Schmerz aufgelöst hat:

• Sicherheits-Check: 7 Warnzeichen, die du übersehen hast — wenn xmlrpc.php geschlossen ist, sind das die nächsten häufigsten Lücken.
• Nach Security der Performance-Hebel: Heartbeat-API drosseln — die zweite WordPress-Standardkonfiguration, die deinen Hoster grundlos belastet.
• Alle 5 kuratierten Code-Snippets im Lab — der vollständige Smart-Fix-Katalog mit Heartbeat, jQuery-Migrate, Emojis, Query-Strings und XML-RPC.

Wenn du sofort messen willst, welche dieser Härtungs- und Optimierungs-Schritte für DEINE Site am dringendsten sind: der 92-Punkt Deep-Audit liefert die individuelle Priorisierung in 60 Sekunden — ohne dass du ein Plugin installieren musst.