Varje WordPress-webbplats lagrar en "tyst" fil i roten som de flesta ägare upptäcker först efter en attack. Den heter xmlrpc.php. Filen i sig är inte skadlig: WordPress varnar ärligt att det är ett gränssnitt för fjärrinteraktion. Men det är genom denna fil som bottar har brutit lösenord, skickat spam-pingbacks och drivit DDoS-trafik i åratal.

Enligt data från Wordfence för 2024 är attacker via XML-RPC bland de fem vanligaste attackvektorerna mot WordPress-webbplatser. En enda system.multicall-förfrågan låter en angripare testa hundratals lösenord på en gång, istället för ett som via inloggningsformuläret. Webbhotell registrerar miljontals sådana försök varje månad på en genomsnittlig sajt.

Låt oss förstå varför denna fil behövs överhuvudtaget, vem som bör behålla den, och viktigast av allt, visa fem sätt att inaktivera eller säkert blockera xmlrpc.php, från ett plugin med ett klick till riktade .htaccess-redigeringar.

💡 Snabb översikt:

• Lär dig vad xmlrpc.php är och vilka WordPress-funktioner som är beroende av den (pingback, mobilapp, Jetpack)
• Bedöm verkliga risker: brute-force-förstärkning, pingback-DDoS och katalogskanning av bottar
• Välj rätt skyddsmetod: inaktivering via plugin, blockering genom .htaccess, stänga åtkomst på webbservernivå eller ta bort filen
• Sätt upp övervakning: hur du säkerställer att xmlrpc.php inte längre svarar på förfrågningar

Vad xmlrpc.php är och vilka WordPress-funktioner som är beroende av den

XML-RPC är ett protokoll för fjärranrop som fungerar över HTTP och överför data i XML-format. Tekniken dök upp i slutet av 1990-talet, långt före REST API, och WordPress ärvde den i sina tidiga dagar. Filen xmlrpc.php i webbplatsroten tar emot XML-förfrågningar, bearbetar dem och returnerar ett svar, till exempel publicerar ett inlägg, laddar upp en mediafil eller kontrollerar användarbehörigheter.

I praktiken fungerar flera scenarier genom xmlrpc.php:

• Pingbacks och trackbacks. När någon länkar till ditt inlägg skickar deras webbplats en XML-RPC-förfrågan med en notifiering. Din WordPress kontrollerar länken och, om den är äkta, lägger till pingbacken i kommentarerna.

• Fjärrpublicering. Applikationer som den gamla Windows Live Writer eller skrivbordsklienter (TextMate, MarsEdit) använde XML-RPC för att skriva och skicka inlägg utan att gå in i adminpanelen.

• WordPress mobilapp. Den officiella iOS- och Android-appen förlitade sig på XML-RPC under lång tid, även om den nu alltmer går över till REST API.

• Integrationer. Tjänster som Jetpack (del av dess funktionalitet), IFTTT och vissa SEO-verktyg använder fortfarande XML-RPC för att ansluta till webbplatsen.

Med lanseringen av WordPress REST API i version 4.7 (december 2016) flyttade de flesta moderna integrationer till det nya protokollet. REST API är snabbare, arbetar med JSON istället för XML och är bättre dokumenterat. Icke desto mindre inkluderar WordPress fortfarande xmlrpc.php i varje installation för bakåtkompatibilitet.

Viktig nyans: från och med WordPress 2.6 (redan 2008) är fjärrpubliceringsfunktionalitet via XML-RPC inaktiverad som standard. För att aktivera den måste du uttryckligen kryssa i rutan under "Inställningar → Skriva". Pingbacks och trackbacks fortsätter att fungera samtidigt.

Hur xmlrpc.php är farlig: tre huvudsakliga attackvektorer

WordPress-utvecklare har patchat xmlrpc.php mer än en gång. I version 2.1.2 kunde en autentiserad användare med "contributor"-rättigheter publicera ett inlägg och kringgå begränsningar. I 2.3.1 upptäckte de ett informationsläckage via XML-RPC. Båda hålen stängdes snabbt, men själva protokollet förblev arkitektoniskt sårbart för tre klasser av attacker som fortfarande är relevanta 2026.

Brute-force-förstärkning via system.multicall

Huvudproblemet är metoden system.multicall. Den tillåter att packa flera wp.getUsersBlogs-anrop i en HTTP-förfrågan. Varje anrop kontrollerar ett "användarnamn + lösenord"-par. Så istället för en gissning per förfrågan gör angriparen hundratals. Cloudflare har registrerat toppar på tiotusentals sådana förfrågningar per timme på en enda webbplats.

Det vanliga inloggningsformuläret wp-login.php är begränsat till en inloggning per försök och skyddas enkelt av ett plugin som Wordfence eller Limit Login Attempts. xmlrpc.php kringgår alla dessa begränsare eftersom den fungerar via en annan slutpunkt.

Pingback-DDoS

Pingback-funktionen är utformad som en harmlös notifiering. Men en angripare kan skicka falska pingback-förfrågningar på uppdrag av hundratals webbplatser, och din server kommer att gå och kontrollera varje "länk", vilket belastar CPU, nätverk och databas. Med tillräcklig skala går webbplatsen ner. Sucuri kallar i sin rapport från 2023 pingback-attacker för en av de vanligaste DDoS-vektorerna mot WordPress.

Katalogskanning av bottar

Bottar letar efter xmlrpc.php inte bara i roten utan också i påhittade underkataloger som /2026/01/xmlrpc.php och /blog/xmlrpc.php. Varje sådan förfrågan returnerar en 404 och slösar serverresurser. Även om attacken misslyckades saktar tiotusentals skräpförfrågningar ner webbplatsen och täpper till loggarna. I praktiken ser ägare att grafer i cPanel går in i den röda zonen, och orsaken är just bottar som skannar xmlrpc.php.

5 Sätt att inaktivera eller säkra xmlrpc.php

Nedan finns fem metoder, från den enklaste till den mest radikala. Välj baserat på din situation: om du använder mobilappen, om du behöver pingbacks, vilket webbhotell du har.

1. Inaktivera via plugin

Den säkraste vägen för dem som inte vill röra koden. Installera ett plugin, så blockerar det åtkomst till xmlrpc.php på WordPress-nivå, innan förfrågningsbearbetningen börjar.

Fördelar: inget behov av att redigera .htaccess eller functions.php, lätt att slå på igen. Nackdelar: lägger till ytterligare ett plugin i adminpanelen, skyddet tas bort vid avaktivering.

Ett par beprövade alternativ:

• Disable XML-RPC, minimalistiskt, en åtgärd: aktiverat, och åtkomst är stängd. Inga inställningar.
• Wordfence Security, omfattande brandvägg där inaktivering av XML-RPC bara är en av funktionerna. Passar om du redan använder Wordfence eller planerar att installera det.

2. Blockera via.htaccess

Om du arbetar på en Apache-server tillåter filen .htaccess i webbplatsroten dig att blockera åtkomst innan förfrågan når WordPress. Detta minskar belastningen: Apache returnerar 403 Forbidden omedelbart, utan att köra PHP.

Lägg till följande block i .htaccess i början av filen, före # BEGIN WordPress:

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

Direktivet RedirectMatch 403 fångar upp alla URL:er som slutar på /xmlrpc.php, inklusive underkataloger som /2025/06/xmlrpc.php, och returnerar omedelbart 403.

Fördelar: rör inte WordPress-kod, fungerar innan PHP laddas, sparar resurser. Nackdelar: behöver redigera .htaccess manuellt, vid byte av webbhotell eller tema kan filen skrivas över.

Viktigt: innan du redigerar .htaccess, gör en säkerhetskopia. Ett syntaxfel i .htaccess kan få webbplatsen att gå ner (500 Internal Server Error).

3. Ta bort länkar via functions.php

Denna metod blockerar inte själva filen men tar bort HTML-länkar till xmlrpc.php och wlwmanifest.xml från webbplatsens <head>-sektion. Fördelen är minskad synlighet: bottar som tolkar HTML ser inte en direkt pekare till XML-RPC-slutpunkten.

Lägg till i det aktiva temats functions.php (eller via Code Snippets-pluginet):

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

Hooken rsd_link matar ut <link rel="EditURI">, en länk till xmlrpc.php för Really Simple Discovery-klienter. Hooken wlwmanifest_link är för Windows Live Writer (länge utan support, men WordPress matar fortfarande ut den).

Fördelar: ren <head> utan skräplänkar. Nackdelar: xmlrpc.php förblir fysiskt tillgänglig via direkt URL, detta är inte blockering utan maskering.

4. Stäng åtkomst via WAF eller Cloudflare

Web Application Firewall blockerar förfrågningar till xmlrpc.php innan de når din server. Detta är den mest effektiva metoden för webbplatser på alla webbhotell.

Konfigurationsalternativ:

• Cloudflare (gratisnivå): WAF-regel → Blockera → Fältet URI Path innehåller /xmlrpc.php. Förfrågan avvisas på Cloudflares nätverksnivå, din server ser den inte ens.
• Wordfence WAF: Inbyggd "Inaktivera XML-RPC"-funktion i brandväggssektionen.
• Webbhotellets WAF: Kinsta, WP Engine och andra hanterade webbhotell låter dig inaktivera XML-RPC med ett par klick via kontrollpanelen.

Fördelar: noll serverbelastning, kan finjusteras (till exempel tillåt Jetpack medan allt annat blockeras). Nackdelar: kräver konfiguration på WAF-sidan, alla webbhotell erbjuder inte denna möjlighet.

5. Ta bort eller byt namn på själva filen

Den mest radikala metoden. Du tar bort (eller byter namn på) filen xmlrpc.php från servern. Om filen fysiskt inte existerar finns det inget att bearbeta förfrågningar, servern returnerar 404.

Viktig nyans: vid nästa WordPress-uppdatering kommer filen att återställas. Automatiska kärnuppdateringar skriver över alla WordPress-filer, inklusive xmlrpc.php. Så borttagning är en tillfällig åtgärd om du inte sätter upp regelbunden rensning.

Om du går denna väg, komplettera borttagningen med .htaccess-regeln från metod 2. Utan den kommer bottar att fortsätta knacka på URL:en xmlrpc.php, och servern kommer ärligt att returnera 404 på varje förfrågan, tusentals fel i loggarna.

Är det ens värt att inaktivera xmlrpc.php?

Svaret beror på vad du använder. Gå igenom checklistan:

Om du inte använder en gammal version av mobilappen, inte har aktiverat Jetpack-hantering med WordPress.com och pingbacks inte är kritiska för dig, inaktivera utan tvekan. År 2026 täcker REST API nästan alla verkliga scenarier.

Video: hur du inaktiverar XML-RPC i WordPress på 5 minuter

Se en visuell guide för att inaktivera xmlrpc.php, med skärmdemonstration och förklaring av varje metod:

⁉️🤔 Vanliga frågor

Är det säkert att bara ignorera xmlrpc.php?

I de flesta fall, nej. Även om du inte använder XML-RPC skannar bottar denna slutpunkt konstant. Varje sådan förfrågan belastar servern. Bättre att uttryckligen stänga åtkomst via .htaccess eller plugin, detta tar bort både brute-force-risken och skräpförfrågningar i loggarna.

Kommer webbplatsen att gå sönder om xmlrpc.php inaktiveras?

WordPress självt kommer att fortsätta fungera utan förändringar. Kontrollera bara om du använder Jetpack-hantering med WordPress.com eller en gammal version av mobilappen. Om inte, inaktivera utan oro. Pingbacks kommer att sluta komma, men de flesta webbplatser använder dem ändå inte för verklig kommunikation.

Hur kontrollerar jag att xmlrpc.php faktiskt är blockerad?

Öppna i din webbläsare https://your-site.com/xmlrpc.php. Om du ser en vit skärm med meddelandet "XML-RPC server accepts POST requests only" är filen vid liv och svarar. Om du får 403 Forbidden eller 404 Not Found fungerar blockeringen. För automatisk övervakning kan du använda onlinekontroller som xmlrpc.eror.xyz eller en curl-förfrågan från konsolen.

Vad är bättre: plugin eller.htaccess?

.htaccess blockerar förfrågan innan WordPress startar, detta sparar serverresurser. Ett plugin är lättare att installera och kräver inte redigering av filer. För icke-kritiska webbplatser är det nästan ingen skillnad. För högbelastningsprojekt är .htaccess eller en WAF-regel att föredra.

Behöver jag uppdatera WordPress efter att ha inaktiverat xmlrpc.php?

Nej. Inaktivering av xmlrpc.php är inte beroende av WordPress-version och påverkar inte kärnuppdateringar. Den enda nyansen: om du tog bort filen fysiskt kommer uppdateringen att återställa den, vilket kräver borttagning igen.

Så vad bör du göra med xmlrpc.php på din webbplats?

Det finns inget universellt svar, sammanhanget avgör allt. Men praktiken från tusentals WordPress-webbplatser ger en tydlig bild: om du inte vet om du behöver XML-RPC, behöver du det inte.

Vill du ha tillförlitlighet utan att dyka in i kod, installera Disable XML-RPC. Redo att lägga fem minuter på .htaccess, få skydd på servernivå utan extra plugins. Använder du Cloudflare, sätt upp en WAF-regel och glöm problemet.

Huvudsaken är att inte lämna xmlrpc.php öppen "som standard". År 2026 är varje ostängd WordPress-slutpunkt ett mål för automatiserade bottar som inte bryr sig om du har en blogg eller en webbutik. Stäng åtkomst med en av metoderna ovan, kontrollera resultatet med en curl-förfrågan och sov lugnt.