Hvert WordPress-nettsted lagrer en «stille» fil i roten som de fleste eiere først oppdager etter et angrep. Den heter xmlrpc.php. Selve filen er ikke ondsinnet: WordPress advarer ærlig om at det er et grensesnitt for ekstern interaksjon. Men det er gjennom denne filen at boter har bruteforcet passord, sendt spam-pingbacks og drevet DDoS-trafikk i årevis.

Ifølge data fra Wordfence for 2024 er angrep via XML-RPC blant de fem vanligste angrepsvektorene mot WordPress-nettsteder. En enkelt system.multicall-forespørsel lar en angriper teste hundrevis av passord samtidig, i stedet for ett som via påloggingsskjemaet. Hostingleverandører registrerer millioner av slike forsøk månedlig på et gjennomsnittlig nettsted.

La oss forstå hvorfor denne filen i det hele tatt trengs, hvem som bør beholde den, og viktigst av alt, vise fem måter å deaktivere eller sikkert blokkere xmlrpc.php på, fra en ett-klikks plugin til målrettede .htaccess-redigeringer.

💡 Hurtigoversikt:

• Lær hva xmlrpc.php er og hvilke WordPress-funksjoner som avhenger av den (pingback, mobilapp, Jetpack)
• Vurder reelle risikoer: brute-force-forsterkning, pingback-DDoS og katalogskanning fra boter
• Velg riktig beskyttelsesmetode: deaktivering via plugin, blokkering gjennom .htaccess, stenging av tilgang på webservernivå eller fjerning av filen
• Sett opp overvåking: hvordan sikre at xmlrpc.php ikke lenger svarer på forespørsler

Hva xmlrpc.php er og hvilke WordPress-funksjoner som avhenger av den

XML-RPC er en protokoll for eksterne prosedyrekall som fungerer over HTTP og overfører data i XML-format. Teknologien dukket opp på slutten av 1990-tallet, lenge før REST API, og WordPress arvet den i sine tidlige dager. Filen xmlrpc.php i nettstedets rot mottar XML-forespørsler, behandler dem og returnerer et svar, for eksempel publiserer et innlegg, laster opp en mediefil eller sjekker brukertillatelser.

I praksis fungerer flere scenarier gjennom xmlrpc.php:

• Pingbacks og trackbacks. Når noen lenker til innlegget ditt, sender nettstedet deres en XML-RPC-forespørsel med et varsel. Din WordPress sjekker lenken, og hvis den er ekte, legger den til pingbacken i kommentarene.

• Ekstern publisering. Applikasjoner som den gamle Windows Live Writer eller skrivebordsklienter (TextMate, MarsEdit) brukte XML-RPC til å skrive og sende innlegg uten å gå inn i administrasjonspanelet.

• WordPress-mobilapp. Den offisielle iOS- og Android-appen støttet seg på XML-RPC i lang tid, selv om den i økende grad går over til REST API nå.

• Integrasjoner. Tjenester som Jetpack (del av funksjonaliteten), IFTTT og noen SEO-verktøy bruker fortsatt XML-RPC for å koble seg til nettstedet.

Med lanseringen av WordPress REST API i versjon 4.7 (desember 2016) gikk de fleste moderne integrasjoner over til den nye protokollen. REST API er raskere, fungerer med JSON i stedet for XML og er bedre dokumentert. Likevel inkluderer WordPress fortsatt xmlrpc.php i hver installasjon for bakoverkompatibilitet.

Viktig nyanse: fra og med WordPress 2.6 (tilbake i 2008) er funksjonalitet for ekstern publisering via XML-RPC deaktivert som standard. For å aktivere den må du eksplisitt krysse av i boksen under «Innstillinger → Skriving». Pingbacks og trackbacks fortsetter å fungere samtidig.

Hvordan xmlrpc.php er farlig: tre hovedangrepsvektorer

WordPress-utviklere har patchet xmlrpc.php mer enn én gang. I versjon 2.1.2 kunne en autentisert bruker med «bidragsyter»-rettigheter publisere et innlegg utenom restriksjoner. I 2.3.1 oppdaget de en informasjonslekkasje gjennom XML-RPC. Begge hullene ble raskt lukket, men selve protokollen forble arkitektonisk sårbar for tre angrepsklasser som fortsatt er relevante i 2026.

Brute-force-forsterkning via system.multicall

Hovedproblemet er system.multicall-metoden. Den tillater å pakke flere wp.getUsersBlogs-kall inn i én HTTP-forespørsel. Hvert kall sjekker et «brukernavn + passord»-par. Så i stedet for ett gjett per forespørsel, gjør angriperen hundrevis. Cloudflare har registrert topper på titusenvis av slike forespørsler i timen på et enkelt nettsted.

Det vanlige påloggingsskjemaet wp-login.php er begrenset til ett påloggingsforsøk per forsøk og er lett beskyttet av en plugin som Wordfence eller Limit Login Attempts. xmlrpc.php omgår alle disse begrenserne fordi den fungerer gjennom et annet endepunkt.

Pingback-DDoS

Pingback-funksjonen er designet som et harmløst varsel. Men en angriper kan sende falske pingback-forespørsler på vegne av hundrevis av nettsteder, og serveren din vil gå og sjekke hver «lenke», noe som belaster CPU, nettverk og database. Med tilstrekkelig skala går nettstedet ned. Sucuri kaller i sin rapport for 2023 pingback-angrep en av de vanligste DDoS-vektorene mot WordPress.

Katalogskanning fra boter

Boter ser etter xmlrpc.php ikke bare i roten, men også i oppdiktede underkataloger som /2026/01/xmlrpc.php og /blog/xmlrpc.php. Hver slik forespørsel returnerer en 404 og sløser med serverressurser. Selv om angrepet mislyktes, bremser titusenvis av søppelforespørsler nettstedet og tetter igjen loggene. I praksis ser eiere at grafer i cPanel går i rød sone, og årsaken er nettopp boter som skanner xmlrpc.php.

5 Måter å deaktivere eller sikre xmlrpc.php på

Nedenfor er fem metoder, fra den enkleste til den mest radikale. Velg basert på din situasjon: om du bruker mobilappen, om du trenger pingbacks, hvilken hosting du har.

1. Deaktiver via plugin

Den tryggeste veien for de som ikke vil røre koden. Installer en plugin, så vil den blokkere tilgang til xmlrpc.php på WordPress-nivå, før forespørselsbehandlingen begynner.

Fordeler: trenger ikke redigere .htaccess eller functions.php, lett å slå på igjen. Ulemper: legger til enda en plugin i administrasjonspanelet, beskyttelsen fjernes ved deaktivering.

Et par velprøvde alternativer:

• Disable XML-RPC, minimalistisk, én handling: aktivert, og tilgang er stengt. Ingen innstillinger.
• Wordfence Security, omfattende brannmur der deaktivering av XML-RPC bare er én av funksjonene. Passer hvis du allerede bruker Wordfence eller planlegger å installere det.

2. Blokker via.htaccess

Hvis du jobber på en Apache-server, lar .htaccess-filen i nettstedets rot deg blokkere tilgang før forespørselen når WordPress. Dette reduserer belastning: Apache returnerer 403 Forbidden umiddelbart, uten å kjøre PHP.

Legg til følgende blokk i .htaccess i begynnelsen av filen, før # BEGIN WordPress:

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

RedirectMatch 403-direktivet fanger opp enhver URL som ender på /xmlrpc.php, inkludert underkataloger som /2025/06/xmlrpc.php, og returnerer øyeblikkelig 403.

Fordeler: rører ikke WordPress-kode, fungerer før PHP lastes, sparer ressurser. Ulemper: må redigere .htaccess manuelt, ved bytte av hosting eller tema kan filen bli overskrevet.

Viktig: før du redigerer .htaccess, ta en sikkerhetskopi. En feil i .htaccess-syntaks kan ta ned nettstedet (500 Internal Server Error).

3. Fjern lenker via functions.php

Denne metoden blokkerer ikke selve filen, men fjerner HTML-lenker til xmlrpc.php og wlwmanifest.xml fra <head>-seksjonen på nettstedet. Fordelen er redusert synlighet: boter som analyserer HTML ser ikke en direkte peker til XML-RPC-endepunktet.

Legg til i det aktive temaets functions.php (eller via Code Snippets-pluginen):

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

rsd_link-hooken sender ut <link rel="EditURI">, en lenke til xmlrpc.php for Really Simple Discovery-klienter. wlwmanifest_link-hooken er for Windows Live Writer (lenge ustøttet, men WordPress sender den fortsatt ut).

Fordeler: ren <head> uten søppellenker. Ulemper: xmlrpc.php forblir fysisk tilgjengelig via direkte URL, dette er ikke blokkering, men maskering.

4. Steng tilgang via WAF eller Cloudflare

Web Application Firewall blokkerer forespørsler til xmlrpc.php før de når serveren din. Dette er den mest effektive tilnærmingen for nettsteder på enhver hosting.

Konfigurasjonsalternativer:

• Cloudflare (gratisnivå): WAF-regel → Blokker → URI Path-feltet inneholder /xmlrpc.php. Forespørselen avvises på Cloudflares nettverksnivå, serveren din ser den ikke engang.
• Wordfence WAF: Innebygd «Deaktiver XML-RPC»-funksjon i brannmurseksjonen.
• Hosting-WAF: Kinsta, WP Engine og andre administrerte hoster lar deg deaktivere XML-RPC med et par klikk gjennom kontrollpanelet.

Fordeler: null serverbelastning, kan finjusteres (for eksempel tillate Jetpack mens alt annet blokkeres). Ulemper: krever konfigurasjon på WAF-siden, ikke alle hostingleverandører tilbyr denne muligheten.

5. Fjern eller omdøp selve filen

Den mest radikale metoden. Du sletter (eller omdøper) xmlrpc.php-filen fra serveren. Hvis filen fysisk ikke eksisterer, er det ingenting å behandle forespørsler, serveren returnerer 404.

Viktig nyanse: ved neste WordPress-oppdatering vil filen bli gjenopprettet. Automatiske kjerneoppdateringer overskriver alle WordPress-filer, inkludert xmlrpc.php. Så sletting er et midlertidig tiltak med mindre du setter opp regelmessig opprydding.

Hvis du går denne veien, suppler slettingen med .htaccess-regelen fra metode 2. Uten den vil boter fortsette å banke på xmlrpc.php-URL-en, og serveren vil ærlig returnere 404 på hver forespørsel, tusenvis av feil i loggene.

Er det i det hele tatt verdt å deaktivere xmlrpc.php?

Svaret avhenger av hva du bruker. Gå gjennom sjekklisten:

Hvis du ikke bruker en gammel versjon av mobilappen, ikke har aktivert Jetpack-administrasjon med WordPress.com, og pingbacks ikke er kritiske for deg, deaktiver den uten å nøle. I 2026 dekker REST API nesten alle reelle scenarier.

Video: hvordan deaktivere XML-RPC i WordPress på 5 minutter

Se en visuell guide til deaktivering av xmlrpc.php, med skjermdemonstrasjon og forklaring av hver metode:

⁉️🤔 Ofte stilte spørsmål

Er det trygt å bare ignorere xmlrpc.php?

I de fleste tilfeller, nei. Selv om du ikke bruker XML-RPC, skanner boter dette endepunktet konstant. Hver slik forespørsel belaster serveren. Bedre å eksplisitt stenge tilgang via .htaccess eller plugin, dette fjerner både brute-force-risikoen og søppelforespørsler i loggene.

Vil nettstedet ødelegges hvis xmlrpc.php deaktiveres?

WordPress selv vil fortsette å fungere uten endringer. Bare sjekk om du bruker Jetpack-administrasjon med WordPress.com eller en gammel versjon av mobilappen. Hvis ikke, deaktiver uten bekymring. Pingbacks vil slutte å komme, men de fleste nettsteder bruker dem uansett ikke til reell kommunikasjon.

Hvordan sjekke at xmlrpc.php faktisk er blokkert?

Åpne i nettleseren din https://your-site.com/xmlrpc.php. Hvis du ser en hvit skjerm med meldingen «XML-RPC server accepts POST requests only», er filen i live og svarer. Hvis du får 403 Forbidden eller 404 Not Found, fungerer blokkeringen. For automatisk overvåking kan du bruke nettsjekkere som xmlrpc.eror.xyz eller en curl-forespørsel fra konsollen.

Hva er best: plugin eller.htaccess?

.htaccess blokkerer forespørselen før WordPress starter, dette sparer serverressurser. En plugin er lettere å installere og krever ikke redigering av filer. For ikke-kritiske nettsteder er det nesten ingen forskjell. For høybelastningsprosjekter er .htaccess eller en WAF-regel å foretrekke.

Trenger jeg å oppdatere WordPress etter å ha deaktivert xmlrpc.php?

Nei. Deaktivering av xmlrpc.php avhenger ikke av WordPress-versjon og påvirker ikke kjerneoppdateringer. Den eneste nyansen: hvis du slettet filen fysisk, vil oppdateringen gjenopprette den, noe som krever sletting på nytt.

Så hva bør du gjøre med xmlrpc.php på nettstedet ditt?

Det finnes ikke noe universelt svar, kontekst avgjør alt. Men praksisen til tusenvis av WordPress-nettsteder gir et klart bilde: hvis du ikke vet om du trenger XML-RPC, trenger du det ikke.

Ønsker du pålitelighet uten å dykke ned i kode, installer Disable XML-RPC. Klar til å bruke fem minutter på .htaccess, få beskyttelse på servernivå uten ekstra plugins. Bruker du Cloudflare, sett opp en WAF-regel og glem problemet.

Hovedsaken er ikke å la xmlrpc.php stå åpen «som standard». I 2026 er hvert ulukket WordPress-endepunkt et mål for automatiserte boter som ikke bryr seg om du har en blogg eller en nettbutikk. Steng tilgangen ved hjelp av en av metodene ovenfor, sjekk resultatet med en curl-forespørsel, og sov trygt.