Nettstedet ditt er tregt, hostingleverandøren sender advarsler om overskredne grenser, og loggene viser en endeløs strøm av POST-forespørsler til xmlrpc.php. Hvis du administrerer WordPress, er dette marerittet sannsynligvis kjent.

Filen xmlrpc.php er et stille, men ekstremt farlig element i enhver WordPress-installasjon. Den har ligget i nettstedets rot siden CMS-installasjonen og har vært et yndet inngangspunkt for boter og angripere i flere tiår. Ifølge Wordfence-rapporten for 2024 er XML-RPC-angrep blant de fem største trusselvektorene for WordPress-nettsteder, og ingenting har endret seg i 2026.

Likevel har de fleste nettstedseiere ingen anelse om hvorfor denne filen i det hele tatt eksisterer, eller hvordan de skal nøytralisere den. Denne guiden dekker fire fungerende metoder for å blokkere xmlrpc.php, fra en rask .htaccess-regel til en brannmur på CDN-nivå. Ingen fyllstoff, bare testet kode og forklaringer på når hver metode bør brukes.

💡 Rask oversikt:

• Sjekk om din xmlrpc.php svarer på POST-forespørsler (det gjør den sannsynligvis)
• Velg en blokkeringsmetode: htaccess, kode i functions.php, plugin eller WAF
• Legg til blokkeringsregelen og bekreft at endepunktet returnerer 403 Forbidden
• Hvis du bruker Jetpack, konfigurer målrettet brannmurbeskyttelse i stedet for å deaktivere helt

Hva er xmlrpc.php og hvorfor er den fortsatt i WordPress

XML-RPC (Remote Procedure Call) er en protokoll som lar eksterne applikasjoner kommunisere med WordPress. Den ble lagt til i kjernen tilbake i versjon 1.5 og fungerte i flere tiår som det eneste API-et for ekstern publisering: WordPress-mobilapper, skrivebordsklienter som Windows Live Writer og tredjepartstjenester var alle avhengige av den.

Med lanseringen av WordPress REST API i versjon 4.7 (2016) forsvant behovet for XML-RPC i stor grad. Det moderne REST API-et dekker alt XML-RPC pleide å gjøre, og gjør det sikrere, raskere og med skikkelig autentisering via nonce eller OAuth.

Men filen xmlrpc.php ligger fortsatt i roten av hver WordPress-installasjon. Ekstern publisering gjennom den er deaktivert som standard, men endepunktet aksepterer likevel forespørsler. Bare åpne yoursite.com/xmlrpc.php i en nettleser for å se: «XML-RPC server accepts POST requests only». Dette betyr at endepunktet er aktivt og klart for angrep.

Hvorfor xmlrpc.php er farlig: hovedangrepsvektorer

Angripere bruker xmlrpc.php til to hovedtyper angrep, og begge kan ta ned nettstedet ditt.

Brute force via system.multicall. Metoden system.multicall lar deg pakke hundrevis av autentiseringsforsøk inn i ÉN HTTP-forespørsel. I stedet for å teste passord ett om gangen (som via wp-login.php), sender en bot en matrise med pålogginger og passord samtidig. Standard plugins for påloggingsbegrensning oppdager ikke slike forespørsler; for dem ser det ut som «ett forsøk». Resultat: angripere sykler gjennom tusenvis av kombinasjoner i løpet av sekunder uten å utløse blokkeringer.

Pingback DDoS. Pingback-funksjonen lar et annet nettsted varsle din WordPress om en lenke til det. En angriper sender en forfalsket pingback-forespørsel og bytter ut offerets IP-adresse som «kilden». Serveren din går pliktoppfyllende for å bekrefte lenken og angriper en intetanende målvert. Skaler dette over tusenvis av kompromitterte WordPress-installasjoner, og du får et distribuert DDoS-angrep der nettstedet ditt fungerer som kanonføde.

Hostingleverandører sporer utgående trafikk av denne typen og kan fryse kontoen din for «deltakelse i DDoS». I mellomtiden kaster serveren din bort CPU, minne og båndbredde på å betjene søppelforespørsler.

Sjekk: svarer din xmlrpc.php

Før du blokkerer, sørg for at endepunktet faktisk er åpent. Åpne dette i nettleseren din:

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

Hvis du ser strengen «XML-RPC server accepts POST requests only», er endepunktet aktivt, og angripere kan sende forespørsler til det. Hvis du får 403 Forbidden eller 404, fungerer beskyttelsen allerede.

Andre metode: send en test POST-forespørsel via terminal:

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

Et svar med 200 OK og en XML-struktur bekrefter: XML-RPC aksepterer forespørsler og er klar for utnyttelse.

Metode 1: rask blokkering via.htaccess

Den enkleste og mest effektive metoden er å blokkere tilgang til filen på webservernivå. Forespørselen avvises før den når WordPress, noe som sparer serverressurser og fungerer selv om nettstedet er under belastning.

Legg til dette i rotens .htaccess (den som ligger ved siden av 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 er Apache 2.4+-syntaks, gjeldende for alle moderne hostingleverandører. Etter lagring åpner du xmlrpc.php i nettleseren din; du skal få 403 Forbidden.

Hvis serveren din kjører nginx, legg til regelen i konfigurasjonen for den virtuelle verten:

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

Etter å ha endret nginx-konfigurasjonen, husk å laste serveren på nytt: sudo nginx -s reload.

Denne metoden fungerer hvis du DEFINITIVT ikke trenger XML-RPC, ikke for Jetpack, ikke for WordPress-mobilapper, ikke for WooCommerce-integrasjoner.

Metode 2: deaktivering via functions.php (programmatisk metode)

Hvis du foretrekker å løse problemet på kodenivå i stedet for serverkonfigurasjoner, her er to testede kodebiter for ditt aktive temas functions.php eller Code Snippets.

Fullstendig deaktivering av XML-RPC (WP 3.5+):

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

Én linje, og WordPress slutter å behandle eventuelle XML-RPC-forespørsler. Ved forsøk på tilgang til xmlrpc.php mottar klienten et feilsvar; selve filen forblir på serveren, men er funksjonelt død.

Rensing av wp_head-headere fra RSD- og WLW-lenker:

Selv etter deaktivering av XML-RPC WordPress fortsetter å sette inn to linjer i <head> som avslører informasjon om nettstedet ditt:

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');

Hookene rsd_link og wlwmanifest_link legger til <link rel="EditURI"> og <link rel="wlwmanifest">-tagger i <head>; disse eksisterer utelukkende for XML-RPC-klienter og tjener ingen praktisk hensikt i 2026. Fjern dem.

⚠️ Viktig: redigeringer i temaets functions.php vil gå tapt ved oppdatering. Bruk et child theme eller Code Snippets-pluginen for permanent lagring av tilpasset kode.

Metode 3: sikkerhetsplugins

Hvis du ikke vil røre kode, installer en plugin. Tre testede alternativer:

• Wordfence Security. Den mest populære WordPress-brannmuren. I tillegg til å blokkere XML-RPC, tilbyr den en malware-skanner, påloggingsbeskyttelse og trafikkovervåking. I Wordfence-innstillinger → Login Security → kryss av for «Disable XML-RPC authentication».

• Disable XML-RPC-API. En lettvektsplugin som gjør nøyaktig én ting: hooker filteret xmlrpc_enabled og deaktiverer endepunktet. Ingen ekstra innstillinger; aktiver og glem.

• iThemes Security (Solid Security). En omfattende plugin med en WordPress Tweaks-modul der XML-RPC deaktiveres med et enkelt avkrysningsvalg. Den lukker også andre vektorer: endring av tabellprefiks, deaktivering av filredigering fra admin, brute force-beskyttelse.

Etter aktivering av noen av disse pluginene, bekreft alltid at xmlrpc.php returnerer en feil, ikke en hilsen.

Metode 4: blokkering på brannmurnivå (Cloudflare / Sucuri)

Det kraftigste beskyttelsesnivået er en webrannmur som forkaster ondsinnede forespørsler før de i det hele tatt når din hosting.

Cloudflare** WAF.** Opprett en tilpasset regel: URI Path-feltet inneholder xmlrpc.php → handling Block. Forespørsler filtreres på Cloudflares nettverksnivå (over 330 tilstedepunkter over hele verden); serveren din ser dem aldri. Free-planen inkluderer 5 tilpassede regler, noe som er nok. Bonus: Cloudflare viser statistikk over blokkerte forespørsler, og du kan se angrepsskalaen med egne øyne.

Sucuri Website Firewall. Lignende tilnærming: en WAF-regel på URI /xmlrpc.php. Sucuri tilbyr også filintegritetsovervåking og automatisk malware-opprydding.

En brannmurregel fungerer godt kombinert med .htaccess eller programmatisk deaktivering: brannmuren kutter av massesøppel, mens den lokale blokkeringen fungerer som en reserve i tilfelle trafikk på en eller annen måte omgår WAF-en.

Hva du skal gjøre hvis du bruker Jetpack

Jetpack fra Automattic bruker XML-RPC for å koble nettstedet ditt med WordPress.com-servere. Hvis du fullstendig deaktiverer xmlrpc.php, slutter Jetpack å fungere: statistikk, abonnementer, bilde-CDN, Related Posts-modulen og Jetpacks brute force-beskyttelse bryter sammen samtidig.

Løsningen: ikke drep XML-RPC helt, men tillat selektivt forespørsler fra Jetpack-servere:

• La xmlrpc.php være tilgjengelig (IKKE blokker via .htaccess og IKKE hook filteret xmlrpc_enabled).

• Konfigurer Cloudflare WAF slik: tillat forespørsler til xmlrpc.php KUN fra Automattics IP-områder (listen oppdateres i Jetpack-dokumentasjonen), blokker resten.

• Som et minimum, fjern RSD- og WLW-headerne ved hjelp av kodebiten fra metode 2, slik at du ikke eksponerer endepunktet i <head> unødvendig.

• Installer Wordfence og aktiver brute force-beskyttelse spesifikt for xmlrpc.php; den blokkerer ikke legitime Jetpack-forespørsler, men kutter passordgjettingsforsøk.

⁉️🤔 Ofte stilte spørsmål

Kan jeg bare slette xmlrpc.php-filen fra serveren?

Du kan, men dette er dårlig praksis. Ved neste WordPress-oppdatering vil filen bli gjenopprettet, og du er sårbar igjen. Det er bedre å blokkere tilgang via .htaccess eller deaktivere funksjonalitet med et filter i kode: effekten er den samme, men kjerneoppdateringer vil ikke ødelegge beskyttelsen din. Hvis du har slettet filen, sørg for å fjerne rsd_link fra wp_head, ellers vil besøkende få en 404 når de følger EditURI-lenken.

Vil deaktivering av XML-RPC ødelegge WooCommerce?

Nei. WooCommerce har fullstendig gått over til WordPress REST API og er ikke avhengig av XML-RPC. Butikken din vil fortsette å fungere uten endringer. Det eneste unntaket er hvis du bruker en gammel, tilpasset løsning knyttet til XML-RPC, men praktisk talt ingen av disse gjenstår.

Hva om hostingleverandøren min allerede blokkerer xmlrpc.php?

Hvis leverandøren allerede har deaktivert XML-RPC på servernivå, trenger du ikke gjøre noe; endepunktet er utilgjengelig. Sjekk: åpne xmlrpc.php; hvis du ser 403, fungerer beskyttelsen. Det eneste som er verdt å legge til er å fjerne RSD- og WLW-headere via functions.php, fordi leverandøren ikke rører disse.

Trenger jeg å deaktivere XML-RPC hvis jeg er på administrert WordPress-hosting?

De fleste administrerte hoster (Kinsta, WP Engine, SiteGround) blokkerer eller begrenser xmlrpc.php strengt på plattformnivå. Sjekk om endepunktet er åpent via nettleser. Hvis blokkert, er ingen ytterligere handling nødvendig. Hvis åpent, legg til .htaccess-regelen: administrerte hoster overskriver den ikke.

Hvordan vet jeg om nettstedet mitt blir angrepet gjennom xmlrpc.php akkurat nå?

Tre tegn: en kraftig økning i serverbelastning med uendret trafikk, hundrevis av identiske POST-forespørsler til xmlrpc.php i tilgangslogger, og minne-/CPU-grensefeil fra hostingleverandøren din. Aktiver overvåking (Wordfence → Live Traffic eller Cloudflare → Security Events); du vil se kilden og omfanget av angrepet i sanntid.

Er det verdt å deaktivere xmlrpc.php i 2026

Kort svar: ja, hvis du ikke bruker Jetpack og ikke publiserer innlegg via WordPress-mobilappen.

XML-RPC er en arv fra WordPress 1.5-tiden. REST API har for lengst tatt dens plass, og xmlrpc.php selv har blitt en åpen dør for brute force- og DDoS-angrep. Å stenge den tar fem minutter. Velg metoden for din situasjon:

• Vil ikke røre kode: installer Disable XML-RPC-API, to klikk.
• Har tilgang til serverfiler: legg til en regel i .htaccess, servernivået er mer pålitelig.
• Foretrekker ren kode: bruk xmlrpc_enabled-filteret og fjern headere med to kodebiter i functions.php.
• Ønsker maksimal beskyttelse: sett opp en WAF-regel i Cloudflare og kombiner den med en lokal blokkering.

Etter blokkering, bekreft alltid at xmlrpc.php returnerer 403 Forbidden, og overvåk logger i minst en uke; du vil bli overrasket over hvor mye søppeltrafikk som forsvinner. Abonner også på WordPress-oppdateringer: historien viser at gamle protokoller dør sakte, og nye XML-RPC-sårbarheter kan dukke opp selv etter 2026.