Jokaisen WordPress-sivuston juuressa on "hiljainen" tiedosto, jonka useimmat omistajat löytävät vasta hyökkäyksen jälkeen. Sen nimi on xmlrpc.php. Tiedosto itsessään ei ole haitallinen: WordPress varoittaa rehellisesti, että se on rajapinta etävuorovaikutukseen. Mutta juuri tämän tiedoston kautta botit ovat vuosien ajan murtaneet salasanoja väsytyshyökkäyksillä, lähettäneet roskapostia pingbackeinä ja ohjanneet DDoS-liikennettä.

Wordfencen vuoden 2024 tietojen mukaan XML-RPC:n kautta tulevat hyökkäykset ovat viiden yleisimmän WordPress-sivustoihin kohdistuvan hyökkäysvektorin joukossa. Yksi system.multicall-pyyntö sallii hyökkääjän testata satoja salasanoja kerralla, toisin kuin kirjautumislomakkeen kautta, jossa testataan yhtä kerrallaan. Palveluntarjoajat rekisteröivät miljoonia tällaisia yrityksiä kuukausittain keskivertosivustolla.

Selvitetään, miksi tätä tiedostoa ylipäätään tarvitaan, kenen kannattaa pitää se, ja mikä tärkeintä, näytämme viisi tapaa poistaa käytöstä tai estää turvallisesti xmlrpc.php aina yhden klikkauksen lisäosasta kohdennettuihin .htaccess-muokkauksiin.

💡 Pikakatsaus:

• Opi, mikä xmlrpc.php on ja mitkä WordPress-toiminnot ovat siitä riippuvaisia (pingback, mobiilisovellus, Jetpack)
• Arvioi todelliset riskit: väsytyshyökkäyksen vahvistaminen, pingback-DDoS ja bottien hakemistoskannaus
• Valitse oikea suojaustapa: käytöstä poistaminen lisäosalla, estäminen .htaccess-tiedoston kautta, pääsyn sulkeminen verkkopalvelimen tasolla tai tiedoston poistaminen
• Määritä valvonta: miten varmistat, ettei xmlrpc.php enää vastaa pyyntöihin

Mikä xmlrpc.php on ja mitkä WordPress-toiminnot ovat siitä riippuvaisia

XML-RPC on etäproseduurikutsujen protokolla, joka toimii HTTP:n yli ja siirtää dataa XML-muodossa. Teknologia ilmestyi 1990-luvun lopulla, kauan ennen REST API:a, ja WordPress peri sen alkuaikoinaan. Sivuston juuressa oleva xmlrpc.php-tiedosto vastaanottaa XML-pyyntöjä, käsittelee ne ja palauttaa vastauksen, esimerkiksi julkaisee artikkelin, lataa mediatiedoston tai tarkistaa käyttöoikeudet.

Käytännössä useat skenaariot toimivat xmlrpc.php-tiedoston kautta:

• Pingbackit ja trackbackit. Kun joku linkittää artikkeliisi, hänen sivustonsa lähettää XML-RPC-pyynnön ilmoituksella. WordPressisi tarkistaa linkin ja, jos se on aito, lisää pingbackin kommentteihin.

• Etäjulkaiseminen. Sovellukset, kuten vanha Windows Live Writer tai työpöytäsovellukset (TextMate, MarsEdit), käyttivät XML-RPC:tä artikkeleiden kirjoittamiseen ja lähettämiseen kirjautumatta hallintapaneeliin.

• WordPress-mobiilisovellus. Virallinen iOS- ja Android-sovellus tukeutui pitkään XML-RPC:hen, vaikka se siirtyykin nyt yhä enemmän REST API:iin.

• Integraatiot. Palvelut, kuten Jetpack (osa sen toiminnoista), IFTTT ja jotkin SEO-työkalut, käyttävät yhä XML-RPC:tä yhteyden muodostamiseen sivustoon.

WordPress REST API:n julkaisun myötä versiossa 4.7 (joulukuu 2016) useimmat nykyaikaiset integraatiot siirtyivät uuteen protokollaan. REST API on nopeampi, toimii JSON:lla XML:n sijaan ja on paremmin dokumentoitu. Tästä huolimatta WordPress sisällyttää xmlrpc.php-tiedoston jokaiseen asennukseen taaksepäin yhteensopivuuden vuoksi.

Tärkeä vivahde: WordPress-versiosta 2.6 lähtien (jo vuonna 2008) etäjulkaisutoiminto XML-RPC:n kautta on oletuksena pois käytöstä. Ota se käyttöön valitsemalla valintaruutu kohdasta "Asetukset → Kirjoittaminen". Pingbackit ja trackbackit toimivat samanaikaisesti edelleen.

Miten xmlrpc.php on vaarallinen: kolme päähyökkäysvektoria

WordPress-kehittäjät ovat paikanneet xmlrpc.php-tiedostoa useammin kuin kerran. Versiossa 2.1.2 todennettu käyttäjä, jolla on "kirjoittajan" oikeudet, pystyi julkaisemaan artikkelin rajoitukset ohittaen. Versiossa 2.3.1 löydettiin tietovuoto XML-RPC:n kautta. Molemmat aukot suljettiin nopeasti, mutta itse protokolla säilyi arkkitehtonisesti haavoittuvaisena kolmelle hyökkäysluokalle, jotka ovat yhä ajankohtaisia vuonna 2026.

Väsytyshyökkäyksen vahvistaminen system.multicallin avulla

Suurin ongelma on system.multicall-metodi. Se mahdollistaa useiden wp.getUsersBlogs-kutsujen pakkaamisen yhteen HTTP-pyyntöön. Jokainen kutsu tarkistaa "käyttäjätunnus + salasana" -parin. Näin ollen hyökkääjä tekee satoja arvauksia yhden pyynnön sijaan. Cloudflare on kirjannut kymmenien tuhansien tällaisten pyyntöjen piikkejä tunnissa yhdelle sivustolle.

Tavallinen kirjautumislomake wp-login.php on rajoitettu yhteen kirjautumisyritykseen kerrallaan, ja se on helppo suojata lisäosalla, kuten Wordfence tai Limit Login Attempts. xmlrpc.php ohittaa kaikki nämä rajoittimet, koska se toimii eri päätepisteen kautta.

Pingback-DDoS

Pingback-ominaisuus on suunniteltu harmittomaksi ilmoitukseksi. Hyökkääjä voi kuitenkin lähettää väärennettyjä pingback-pyyntöjä satojen sivustojen puolesta, ja palvelimesi lähtee tarkistamaan jokaista "linkkiä", kuormittaen suoritinta, verkkoa ja tietokantaa. Riittävässä mittakaavassa sivusto kaatuu. Sucuri kutsuu vuoden 2023 raportissaan pingback-hyökkäyksiä yhdeksi yleisimmistä DDoS-vektoreista WordPressiä vastaan.

Bottien hakemistoskannaus

Botit etsivät xmlrpc.php-tiedostoa paitsi juuresta myös keksityistä alihakemistoista, kuten /2026/01/xmlrpc.php ja /blog/xmlrpc.php. Jokainen tällainen pyyntö palauttaa 404-virheen ja tuhlaa palvelimen resursseja. Vaikka hyökkäys epäonnistuisi, kymmenet tuhannet roskapyynnöt hidastavat sivustoa ja tukkivat lokit. Käytännössä omistajat näkevät cPanelin kuvaajien menevän punaiselle alueelle, ja syynä ovat juuri xmlrpc.php-tiedostoa skannaavat botit.

5 Tapaa poistaa xmlrpc.php käytöstä tai suojata se

Alla on viisi menetelmää yksinkertaisimmasta radikaaleimpaan. Valitse tilanteesi mukaan: käytätkö mobiilisovellusta, tarvitsetko pingbackejä, millainen hosting sinulla on.

1. Poista käytöstä lisäosan avulla

Turvallisin polku niille, jotka eivät halua koskea koodiin. Asenna lisäosa, niin se estää pääsyn xmlrpc.php-tiedostoon WordPress-tasolla, ennen kuin pyynnön käsittely alkaa.

Hyödyt: ei tarvitse muokata .htaccess- tai functions.php-tiedostoa, helppo ottaa takaisin käyttöön. Haitat: lisää yhden lisäosan hallintapaneeliin, suojaus poistuu deaktivoitaessa.

Muutama toimivaksi todettu vaihtoehto:

• Disable XML-RPC, minimalistinen, yksi toiminto: aktivoituna pääsy on suljettu. Ei asetuksia.
• Wordfence Security, kattava palomuuri, jossa XML-RPC:n poistaminen käytöstä on vain yksi toiminnoista. Sopii, jos käytät jo Wordfenceä tai aiot asentaa sen.

2. Estä.htaccessin kautta

Jos käytät Apache-palvelinta, sivuston juuressa oleva .htaccess-tiedosto mahdollistaa pääsyn estämisen ennen kuin pyyntö saavuttaa WordPressin. Tämä vähentää kuormaa: Apache palauttaa 403 Forbidden -virheen välittömästi, ilman PHP:n suorittamista.

Lisää seuraava lohko .htaccess-tiedostoon tiedoston alkuun, ennen # BEGIN WordPress -riviä:

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

RedirectMatch 403 -direktiivi nappaa minkä tahansa URL-osoitteen, joka päättyy /xmlrpc.php-päätteeseen, mukaan lukien alihakemistot, kuten /2025/06/xmlrpc.php, ja palauttaa välittömästi 403-virheen.

Hyödyt: ei koske WordPress-koodiin, toimii ennen PHP:n lataamista, säästää resursseja. Haitat: .htaccess-tiedostoa on muokattava manuaalisesti, hostingia tai teemaa vaihdettaessa tiedosto saattaa korvautua.

Tärkeää: ennen .htaccess-tiedoston muokkaamista, tee varmuuskopio. Syntaksivirhe .htaccess-tiedostossa voi kaataa sivuston (500 Internal Server Error).

3. Poista linkit functions.php:n kautta

Tämä menetelmä ei estä itse tiedostoa, mutta poistaa HTML-linkit xmlrpc.php- ja wlwmanifest.xml-tiedostoihin sivuston <head>-osiosta. Hyöty on näkyvyyden vähentäminen: HTML:ää jäsentävät botit eivät näe suoraa osoitinta XML-RPC-päätepisteeseen.

Lisää aktiivisen teeman functions.php-tiedostoon (tai Code Snippets -lisäosan kautta):

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

rsd_link-koukku tulostaa <link rel="EditURI"> -elementin, linkin xmlrpc.php-tiedostoon Really Simple Discovery -asiakkaita varten. wlwmanifest_link-koukku on Windows Live Writeriä varten (pitkään ilman tukea, mutta WordPress tulostaa sen yhä).

Hyödyt: puhdas <head> ilman roskalinkkejä. Haitat: xmlrpc.php on fyysisesti edelleen käytettävissä suoran URL-osoitteen kautta, tämä ei ole estämistä vaan naamiointia.

4. Sulje pääsy WAF:n tai Cloudflaren kautta

Web Application Firewall estää pyynnöt xmlrpc.php-tiedostoon ennen kuin ne saavuttavat palvelimesi. Tämä on tehokkain lähestymistapa sivustoille millä tahansa hostingilla.

Määritysvaihtoehdot:

• Cloudflare (ilmainen taso): WAF-sääntö → Block → URI Path -kenttä sisältää /xmlrpc.php. Pyyntö hylätään Cloudflaren verkon tasolla, palvelimesi ei edes näe sitä.
• Wordfence WAF: Sisäänrakennettu "Disable XML-RPC" -toiminto palomuuriosiossa.
• Hosting-WAF: Kinsta, WP Engine ja muut hallinnoidut hostaajat antavat poistaa XML-RPC:n käytöstä muutamalla napsautuksella hallintapaneelin kautta.

Hyödyt: nolla palvelinkuormaa, voidaan hienosäätää (esimerkiksi sallia Jetpack samalla kun estetään kaikki muu). Haitat: vaatii WAF-puolen määrityksen, kaikki hosting-palveluntarjoajat eivät tarjoa tätä ominaisuutta.

5. Poista tai nimeä itse tiedosto uudelleen

Radikaalein menetelmä. Poistat (tai nimeät uudelleen) xmlrpc.php-tiedoston palvelimelta. Jos tiedostoa ei fyysisesti ole, ei ole mitään, mikä käsittelisi pyyntöjä, palvelin palauttaa 404-virheen.

Tärkeä vivahde: seuraavassa WordPress-päivityksessä tiedosto palautetaan. Automaattiset ydintiedostopäivitykset korvaavat kaikki WordPress-tiedostot, mukaan lukien xmlrpc.php. Joten poistaminen on väliaikainen toimenpide, ellet määritä säännöllistä siivousta.

Jos valitset tämän reitin, täydennä poistoa menetelmän 2 .htaccess-säännöllä. Ilman sitä botit jatkavat xmlrpc.php-URL-osoitteen koputtelua, ja palvelin palauttaa rehellisesti 404-virheen jokaiseen pyyntöön, tuhansia virheitä lokeihin.

Kannattaako xmlrpc.php ylipäätään poistaa käytöstä?

Vastaus riippuu siitä, mitä käytät. Käy läpi tarkistuslista:

Jos et käytä vanhaa versiota mobiilisovelluksesta, et ole ottanut käyttöön Jetpack-hallintaa WordPress.comin kanssa, eivätkä pingbackit ole sinulle kriittisiä, poista se käytöstä epäröimättä. Vuonna 2026 REST API kattaa lähes kaikki todelliset skenaariot.

Video: miten XML-RPC poistetaan käytöstä WordPressissä 5 minuutissa

Katso visuaalinen opas xmlrpc.php-tiedoston poistamiseen käytöstä, jossa on näyttödemonstraatio ja jokaisen menetelmän selitys:

⁉️🤔 Usein kysytyt kysymykset

Onko turvallista vain jättää xmlrpc.php huomiotta?

Useimmissa tapauksissa ei. Vaikka et käyttäisi XML-RPC:tä, botit skannaavat tätä päätepistettä jatkuvasti. Jokainen tällainen pyyntö kuormittaa palvelinta. On parempi sulkea pääsy nimenomaisesti .htaccess-tiedoston tai lisäosan kautta, tämä poistaa sekä väsytyshyökkäyksen riskin että roskapyynnöt lokeista.

Rikkoutuuko sivusto, jos xmlrpc.php poistetaan käytöstä?

WordPress itse jatkaa toimintaansa ilman muutoksia. Tarkista vain, käytätkö Jetpack-hallintaa WordPress.comin kanssa tai vanhaa versiota mobiilisovelluksesta. Jos et, poista käytöstä huoletta. Pingbackien tulo lakkaa, mutta useimmat sivustot eivät käytä niitä todelliseen viestintään muutenkaan.

Miten tarkistan, että xmlrpc.php on todella estetty?

Avaa selaimessasi https://your-site.com/xmlrpc.php. Jos näet valkoisen ruudun, jossa lukee "XML-RPC server accepts POST requests only", tiedosto on elossa ja vastaa. Jos saat 403 Forbidden- tai 404 Not Found -virheen, esto toimii. Automaattiseen valvontaan voit käyttää online-tarkistimia, kuten xmlrpc.eror.xyz tai curl-pyyntöä konsolista.

Kumpi on parempi: lisäosa vai.htaccess?

.htaccess estää pyynnön ennen WordPressin käynnistymistä, tämä säästää palvelimen resursseja. Lisäosa on helpompi asentaa, eikä vaadi tiedostojen muokkaamista. Ei-kriittisillä sivustoilla eroa ei juuri ole. Korkean kuorman projekteissa .htaccess tai WAF-sääntö on suositeltavampi.

Täytyykö WordPress päivittää xmlrpc.php:n käytöstä poistamisen jälkeen?

Ei. xmlrpc.php:n poistaminen käytöstä ei riipu WordPress-versiosta eikä vaikuta ydintiedostopäivityksiin. Ainoa vivahde: jos poistit tiedoston fyysisesti, päivitys palauttaa sen, mikä vaatii poistamisen uudelleen.

Mitä xmlrpc.php:lle pitäisi siis tehdä sivustollasi?

Yleispätevää vastausta ei ole, konteksti ratkaisee kaiken. Mutta tuhansien WordPress-sivustojen käytäntö antaa selvän kuvan: jos et tiedä, tarvitsetko XML-RPC:tä, et tarvitse sitä.

Haluat luotettavuutta sukeltamatta koodiin, asenna Disable XML-RPC. Olet valmis käyttämään viisi minuuttia .htaccess-tiedostoon, saat palvelintason suojauksen ilman ylimääräisiä lisäosia. Käytät Cloudflarea, määritä WAF-sääntö ja unohda ongelma.

Pääasia on, älä jätä xmlrpc.php-tiedostoa auki "oletuksena". Vuonna 2026 jokainen sulkematon WordPress-päätepiste on maalitaulu automatisoiduille boteille, joita ei kiinnosta, onko sinulla blogi vai verkkokauppa. Sulje pääsy jollakin yllä olevista menetelmistä, tarkista tulos curl-pyynnöllä ja nuku rauhassa.