Din sajt är seg, ditt webbhotell skickar varningar om överskridna gränser och loggarna visar en oändlig ström av POST-anrop till xmlrpc.php. Om du administrerar WordPress är den här mardrömmen förmodligen bekant.

Filen xmlrpc.php är en tyst men extremt farlig del av varje WordPress-installation. Den har legat i din sajts rot sedan CMS:et installerades och har i årtionden varit en favoritingång för bottar och angripare. Enligt Wordfence-rapporten för 2024 rankas XML-RPC-attacker bland de fem främsta hotvektorerna för WordPress-sajter, och ingenting har förändrats under 2026.

Ändå har de flesta sajtägare ingen aning om varför den här filen ens finns eller hur man oskadliggör den. Den här guiden går igenom fyra fungerande metoder för att blockera xmlrpc.php, från en snabb .htaccess-regel till en brandvägg på CDN-nivå. Inget utfyllnad, bara testad kod och förklaringar av när varje metod ska användas.

💡 Snabb översikt:

• Kontrollera om din xmlrpc.php svarar på POST-anrop (det gör den förmodligen)
• Välj en blockeringsmetod: htaccess, kod i functions.php, tillägg eller WAF
• Lägg till blockeringsregeln och verifiera att slutpunkten returnerar 403 Forbidden
• Om du använder Jetpack, konfigurera riktat brandväggsskydd istället för att inaktivera helt

Vad är xmlrpc.php och varför finns den kvar i WordPress

XML-RPC (Remote Procedure Call) är ett protokoll som låter externa applikationer kommunicera med WordPress. Det lades till i kärnan redan i version 1.5 och fungerade i årtionden som det enda API:et för fjärrpublicering: WordPress mobilappar, skrivbordsklienter som Windows Live Writer och tredjepartstjänster förlitade sig alla på det.

I och med lanseringen av WordPress REST API i version 4.7 (2016) försvann behovet av XML-RPC i stort sett. Det moderna REST API:et täcker allt som XML-RPC brukade göra, och gör det säkrare, snabbare och med korrekt autentisering via nonce eller OAuth.

Men filen xmlrpc.php ligger fortfarande kvar i roten på varje WordPress-installation. Fjärrpublicering via den är inaktiverad som standard, men slutpunkten tar ändå emot anrop. Öppna bara yoursite.com/xmlrpc.php i en webbläsare för att se: "XML-RPC server accepts POST requests only". Det betyder att slutpunkten är aktiv och redo för attack.

Varför xmlrpc.php är farlig: huvudsakliga attackvektorer

Angripare använder xmlrpc.php för två huvudtyper av attacker, och båda kan slå ut din sajt.

Brute force via system.multicall. Metoden system.multicall låter dig packa hundratals autentiseringsförsök i ETT enda HTTP-anrop. Istället för att testa lösenord ett i taget (som via wp-login.php) skickar en bot en array med inloggningar och lösenord på en gång. Standardtillägg för inloggningsbegränsning upptäcker inte sådana anrop, för dem ser det ut som "ett försök". Resultat: angripare cyklar igenom tusentals kombinationer på sekunder utan att utlösa blockeringar.

Pingback-DDoS. Pingback-funktionen låter en annan sajt meddela din WordPress om en länk till den. En angripare skickar ett förfalskat pingback-anrop och anger offrets IP-adress som "källa". Din server går pliktskyldigt iväg för att verifiera länken och attackerar en intet ont anande målvärd. Skala upp detta över tusentals komprometterade WordPress-installationer, så får du en distribuerad DDoS-attack där din sajt fungerar som kanonmat.

Webbhotell spårar utgående trafik av det här slaget och kan frysa ditt konto för "deltagande i DDoS". Samtidigt slösar din server CPU, minne och bandbredd på att betjäna skräpanrop.

Kontrollera: svarar din xmlrpc.php

Innan du blockerar, se till att slutpunkten faktiskt är öppen. Öppna detta i din webbläsare:

1
https://yoursite.com/xmlrpc.php

Om du ser strängen "XML-RPC server accepts POST requests only" är slutpunkten aktiv och angripare kan skicka anrop till den. Om du får 403 Forbidden eller 404 fungerar skyddet redan.

Andra metoden: skicka ett test-POST-anrop via terminalen:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Ett svar med 200 OK och en XML-struktur bekräftar: XML-RPC tar emot anrop och är redo att utnyttjas.

Metod 1: snabb blockering via.htaccess

Den enklaste och mest effektiva metoden är att blockera åtkomst till filen på webbservernivå. Anropet avvisas innan det når WordPress, vilket sparar serverresurser och fungerar även om sajten är under belastning.

Lägg till detta i din rot-.htaccess (den som ligger bredvid wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

Direktivet Require all denied är Apache 2.4+-syntax, aktuell för alla moderna webbhotell. Efter att du sparat, öppna xmlrpc.php i din webbläsare; du bör få 403 Forbidden.

Om din server kör nginx, lägg till regeln i den virtuella värdens konfiguration:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Efter att du ändrat nginx-konfigurationen, kom ihåg att ladda om servern: sudo nginx -s reload.

Den här metoden fungerar om du DEFINITIVT inte behöver XML-RPC, varken för Jetpack, WordPress mobilappar eller WooCommerce-integrationer.

Metod 2: inaktivering via functions.php (programmatisk metod)

Om du föredrar att lösa problemet på kodnivå istället för serverkonfigurationer, här är två testade kodsnuttar för ditt aktiva temas functions.php eller Code Snippets.

Fullständig inaktivering av XML-RPC (WP 3.5+):

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

En rad, och WordPress slutar behandla alla XML-RPC-anrop. Vid försök att nå xmlrpc.php får klienten ett felsvar; själva filen finns kvar på servern men är funktionellt död.

Rensa wp_head-headers från RSD- och WLW-länkar:

Även efter inaktivering fortsätter XML-RPC WordPress att infoga två rader i <head> som avslöjar information om din sajt:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Hakarna rsd_link och wlwmanifest_link lägger till <link rel="EditURI"> och <link rel="wlwmanifest">-taggar i <head>; dessa finns enbart till för XML-RPC-klienter och fyller ingen praktisk funktion under 2026. Ta bort dem.

⚠️ Viktigt: redigeringar i temats functions.php försvinner vid uppdatering. Använd ett barntema eller tillägget Code Snippets för permanent lagring av anpassad kod.

Metod 3: säkerhetstillägg

Om du inte vill röra kod, installera ett tillägg. Tre testade alternativ:

• Wordfence Security. Den mest populära WordPress-brandväggen. Förutom att blockera XML-RPC erbjuder den en skanner för skadlig kod, inloggningsskydd och trafikövervakning. I Wordfence-inställningar → Login Security → kryssa i "Disable XML-RPC authentication".

• Disable XML-RPC-API. Ett lättviktigt tillägg som gör exakt en sak: hakar i xmlrpc_enabled-filtret och inaktiverar slutpunkten. Inga ytterligare inställningar; aktivera och glöm.

• iThemes Security (Solid Security). Ett omfattande tillägg med en WordPress Tweaks-modul där XML-RPC inaktiveras med en enda kryssruta. Det stänger också andra vektorer: ändring av tabellprefix, inaktivering av filredigeraren från admin, brute force-skydd.

Efter aktivering av något av dessa tillägg, verifiera alltid att xmlrpc.php returnerar ett fel, inte en hälsning.

Metod 4: blockering på brandväggsnivå (Cloudflare / Sucuri)

Den mest kraftfulla skyddsnivån är en webbbrandvägg som kastar bort skadliga anrop innan de ens når ditt webbhotell.

Cloudflare** WAF.** Skapa en anpassad regel: URI Path-fältet innehåller xmlrpc.php → åtgärd Block. Anrop filtreras på Cloudflares nätverksnivå (över 330 närvaropunkter världen över); din server ser dem aldrig. Free-planen inkluderar 5 anpassade regler, vilket räcker. Bonus: Cloudflare visar statistik över blockerade anrop, och du kan se attackens omfattning med egna ögon.

Sucuri Website Firewall. Liknande tillvägagångssätt: en WAF-regel på URI /xmlrpc.php. Sucuri erbjuder också övervakning av filintegritet och automatisk sanering av skadlig kod.

En brandväggsregel fungerar bra i kombination med .htaccess eller programmatisk inaktivering: brandväggen kapar bort mass-skrap, medan den lokala blockeringen fungerar som en reserv ifall trafik på något sätt går förbi WAF:en.

Vad du ska göra om du använder Jetpack

Jetpack från Automattic använder XML-RPC för att länka din sajt med WordPress.com-servrar. Om du helt inaktiverar xmlrpc.php slutar Jetpack att fungera: statistik, prenumerationer, bild-CDN, modulen Relaterade inlägg och Jetpacks brute force-skydd går alla sönder på en gång.

Lösningen: döda inte XML-RPC helt, utan tillåt selektivt anrop från Jetpacks servrar:

• Lämna xmlrpc.php tillgänglig (blockera INTE via .htaccess och haka INTE i xmlrpc_enabled-filtret).

• Konfigurera Cloudflare WAF så här: tillåt anrop till xmlrpc.php ENDAST från Automattics IP-intervall (listan uppdateras i Jetpacks dokumentation), blockera resten.

• Ta som minimum bort RSD- och WLW-headers med kodsnutten från metod 2, så att du inte exponerar slutpunkten i <head> i onödan.

• Installera Wordfence och aktivera brute force-skydd specifikt för xmlrpc.php; det blockerar inte legitima Jetpack-anrop men stoppar lösenordsgissningsförsök.

⁉️🤔 Vanliga frågor

Kan jag bara radera filen xmlrpc.php från servern?

Du kan, men det är dålig praxis. Vid nästa WordPress-uppdatering återställs filen och du är sårbar igen. Det är bättre att blockera åtkomst via .htaccess eller inaktivera funktionaliteten med ett filter i kod: effekten är densamma, men kärnuppdateringar kommer inte att förstöra ditt skydd. Om du har raderat filen, se till att ta bort rsd_link från wp_head, annars får besökare en 404 när de följer EditURI-länken.

Kommer inaktivering av XML-RPC att förstöra WooCommerce?

Nej. WooCommerce har helt övergått till WordPress REST API och är inte beroende av XML-RPC. Din butik kommer att fortsätta fungera utan förändringar. Det enda undantaget är om du använder en urgammal anpassad lösning kopplad till XML-RPC, men praktiskt taget inga sådana finns kvar.

Vad händer om mitt webbhotell redan blockerar xmlrpc.php?

Om webbhotellet redan har inaktiverat XML-RPC på servernivå behöver du inte göra någonting; slutpunkten är oåtkomlig. Kontrollera: öppna xmlrpc.php; om du ser 403 fungerar skyddet. Det enda som är värt att lägga till är att ta bort RSD- och WLW-headers via functions.php, eftersom webbhotellet inte rör dessa.

Behöver jag inaktivera XML-RPC om jag har ett managed WordPress-webbhotell?

De flesta managed-hosts (Kinsta, WP Engine, SiteGround) blockerar eller begränsar strikt xmlrpc.php på plattformsnivå. Kontrollera om slutpunkten är öppen via webbläsaren. Om den är blockerad krävs ingen ytterligare åtgärd. Om den är öppen, lägg till .htaccess-regeln: managed-hosts skriver inte över den.

Hur vet jag om min sajt attackeras via xmlrpc.php just nu?

Tre tecken: en kraftig topp i serverbelastning med oförändrad trafik, hundratals identiska POST-anrop till xmlrpc.php i åtkomstloggarna och felmeddelanden om minnes-/CPU-gränser från ditt webbhotell. Aktivera övervakning (Wordfence → Live Traffic eller Cloudflare → Security Events); du kommer att se källan och omfattningen av attacken i realtid.

Är det värt att inaktivera xmlrpc.php under 2026

Kort svar: ja, om du inte använder Jetpack och inte publicerar inlägg via WordPress mobilapp.

XML-RPC är ett arv från WordPress 1.5-eran. REST API har för länge sedan tagit dess plats, och xmlrpc.php själv har blivit en öppen dörr för brute force- och DDoS-attacker. Att stänga den tar fem minuter. Välj metod för din situation:

• Vill inte röra kod: installera Disable XML-RPC-API, två klick.
• Har tillgång till serverfiler: lägg till en regel i .htaccess, servernivån är mer tillförlitlig.
• Föredrar ren kod: applicera xmlrpc_enabled-filtret och ta bort headers med två kodsnuttar i functions.php.
• Vill ha maximalt skydd: sätt upp en WAF-regel i Cloudflare och kombinera den med en lokal blockering.

Efter blockering, verifiera alltid att xmlrpc.php returnerar 403 Forbidden, och övervaka loggar i minst en vecka; du kommer att bli förvånad över hur mycket skräptrafik som försvinner. Prenumerera också på WordPress-uppdateringar: historien visar att gamla protokoll dör långsamt, och nya XML-RPC-sårbarheter kan dyka upp även efter 2026.