Sivustosi on hidas, hosting-palveluntarjoajasi lähettää varoituksia ylitetyistä rajoista, ja lokit näyttävät loputonta POST-pyyntöjen virtaa tiedostoon xmlrpc.php. Jos hallinnoit WordPressiä, tämä painajainen on luultavasti tuttu.

xmlrpc.php-tiedosto on minkä tahansa WordPress-asennuksen hiljainen mutta äärimmäisen vaarallinen osa. Se on asunut sivustosi juuressa CMS:n asennuksesta lähtien ja on pysynyt bottien ja hyökkääjien suosimana sisääntuloväylänä vuosikymmeniä. Vuoden 2024 Wordfence-raportin mukaan XML-RPC-hyökkäykset kuuluvat viiden suurimman WordPress-sivustojen uhkavektorin joukkoon, eikä mikään ole muuttunut vuonna 2026.

Silti useimmilla sivuston omistajilla ei ole aavistustakaan, miksi tämä tiedosto on edes olemassa tai miten se neutralisoidaan. Tämä opas kattaa neljä toimivaa tapaa estää xmlrpc.php, nopeasta .htaccess-säännöstä CDN-tason palomuuriin. Ei turhaa höttöä, vain testattua koodia ja selitykset siitä, milloin kutakin menetelmää kannattaa käyttää.

💡 Pikakatsaus:

• Tarkista, vastaako xmlrpc.php-tiedostosi POST-pyyntöihin (luultavasti vastaa)
• Valitse estomenetelmä: htaccess, koodi functions.php-tiedostossa, lisäosa tai WAF
• Lisää estävä sääntö ja varmista, että päätepiste palauttaa 403 Forbidden -virheen
• Jos käytät Jetpackia, määritä kohdennettu palomuurisuoja täydellisen käytöstä poistamisen sijaan

Mikä on xmlrpc.php ja miksi se on yhä WordPressissä

XML-RPC (Remote Procedure Call) on protokolla, joka sallii ulkoisten sovellusten kommunikoida WordPressin kanssa. Se lisättiin ytimeen jo versiossa 1.5 ja toimi vuosikymmeniä ainoana API-rajapintana etäjulkaisemiseen: WordPress-mobiilisovellukset, työpöytäasiakkaat kuten Windows Live Writer ja kolmannen osapuolen palvelut kaikki luottivat siihen.

WordPress REST API:n julkaisun myötä versiossa 4.7 (2016) XML-RPC:n tarve katosi suurelta osin. Moderni REST API kattaa kaiken, mitä XML-RPC ennen teki, ja tekee sen turvallisemmin, nopeammin ja asianmukaisella todennuksella noncen tai OAuthin kautta.

Mutta xmlrpc.php-tiedosto istuu yhä jokaisen WordPress-asennuksen juuressa. Etäjulkaiseminen sen kautta on oletuksena pois käytöstä, mutta päätepiste ottaa silti vastaan pyyntöjä. Avaa vain yoursite.com/xmlrpc.php selaimessa nähdäksesi: "XML-RPC server accepts POST requests only". Tämä tarkoittaa, että päätepiste on elossa ja valmis hyökkäystä varten.

Miksi xmlrpc.php on vaarallinen: tärkeimmät hyökkäysvektorit

Hyökkääjät käyttävät xmlrpc.php-tiedostoa kahteen pääasialliseen hyökkäystyyppiin, ja molemmat voivat kaataa sivustosi.

Brute force system.multicall-metodin kautta. system.multicall-metodin avulla voit pakata satoja todennusyrityksiä YHTEEN HTTP-pyyntöön. Sen sijaan, että salasanoja testattaisiin yksi kerrallaan (kuten wp-login.php-tiedoston kautta), botti lähettää joukon käyttäjätunnuksia ja salasanoja kerralla. Tavalliset kirjautumisen rajoitinlisäosat eivät havaitse tällaisia pyyntöjä, niille se näyttää "yhdeltä yritykseltä". Lopputulos: hyökkääjät käyvät läpi tuhansia yhdistelmiä sekunneissa laukaisematta estoja.

Pingback DDoS. Pingback-toiminto sallii toisen sivuston ilmoittaa WordPressillesi linkistä siihen. Hyökkääjä lähettää väärennetyn pingback-pyynnön korvaten uhrin IP-osoitteen "lähteenä". Palvelimesi lähtee tunnollisesti tarkistamaan linkkiä ja hyökkää pahaa-aavistamattoman kohdeisännän kimppuun. Skaalaa tämä tuhansiin vaarantuneisiin WordPress-asennuksiin, ja saat hajautetun DDoS-hyökkäyksen, jossa sivustosi toimii tykinruokana.

Hosting-palveluntarjoajat seuraavat tällaista lähtevää liikennettä ja saattavat jäädyttää tilisi "DDoSiin osallistumisesta". Samaan aikaan palvelimesi tuhlaa suoritintehoa, muistia ja kaistaa roskapyyntöjen palvelemiseen.

Tarkista: vastaako xmlrpc.php-tiedostosi

Ennen estämistä varmista, että päätepiste on todella auki. Avaa tämä selaimessasi:

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

Jos näet merkkijonon "XML-RPC server accepts POST requests only", päätepiste on elossa ja hyökkääjät voivat lähettää siihen pyyntöjä. Jos saat 403 Forbidden tai 404 -virheen, suojaus on jo toiminnassa.

Toinen tapa: lähetä testi-POST-pyyntö terminaalin kautta:

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

Vastaus, jossa on 200 OK ja XML-rakenne, vahvistaa: XML-RPC ottaa vastaan pyyntöjä ja on valmis hyväksikäytettäväksi.

Tapa 1: nopea esto.htaccess-tiedoston kautta

Yksinkertaisin ja tehokkain tapa on estää pääsy tiedostoon verkkopalvelimen tasolla. Pyyntö hylätään ennen kuin se saavuttaa WordPressin, mikä säästää palvelimen resursseja ja toimii, vaikka sivusto olisi kuormitettuna.

Lisää tämä sivustosi juuren .htaccess-tiedostoon (siihen, joka on wp-config.php-tiedoston vieressä):

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

Require all denied -direktiivi on Apache 2.4+ -syntaksia, ajankohtainen kaikille moderneille hosting-palveluntarjoajille. Tallenna ja avaa xmlrpc.php selaimessasi; sinun pitäisi saada 403 Forbidden.

Jos palvelimesi käyttää nginxiä, lisää sääntö virtuaalipalvelimen konfiguraatioon:

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

Nginx-konfiguraation muuttamisen jälkeen muista ladata palvelin uudelleen: sudo nginx -s reload.

Tämä menetelmä toimii, jos et EHDOTTOMASTI tarvitse XML-RPC:tä, et Jetpackille, et WordPress-mobiilisovelluksille etkä WooCommerce-integraatioille.

Tapa 2: käytöstä poistaminen functions.php-tiedoston kautta (ohjelmallinen tapa)

Jos haluat mieluummin ratkaista ongelman kooditasolla palvelinkonfiguraatioiden sijaan, tässä on kaksi testattua koodinpätkää aktiivisen teemasi functions.php-tiedostoon tai Code Snippets -lisäosaan.

Täydellinen XML-RPC:n poistaminen käytöstä (WP 3.5+):

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

Yksi rivi, ja WordPress lopettaa kaikkien XML-RPC-pyyntöjen käsittelyn. Yrittäessään käyttää xmlrpc.php-tiedostoa asiakas saa virhevastauksen; itse tiedosto jää palvelimelle, mutta on toiminnallisesti kuollut.

wp_head-otsakkeiden puhdistaminen RSD- ja WLW-linkeistä:

Jopa XML-RPC WordPressin käytöstä poistamisen jälkeen se jatkaa kahden rivin lisäämistä <head>-osioon, jotka paljastavat tietoa sivustostasi:

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

rsd_link- ja wlwmanifest_link-koukut lisäävät <link rel="EditURI">- ja <link rel="wlwmanifest">-tagit <head>-osioon; nämä ovat olemassa yksinomaan XML-RPC-asiakkaita varten, eikä niillä ole mitään käytännön tarkoitusta vuonna 2026. Poista ne.

⚠️ Tärkeää: teeman functions.php-tiedostoon tehdyt muokkaukset katoavat päivityksen yhteydessä. Käytä lapsiteemaa tai Code Snippets -lisäosaa mukautetun koodin pysyvään tallentamiseen.

Tapa 3: tietoturvalisäosat

Jos et halua koskea koodiin, asenna lisäosa. Kolme testattua vaihtoehtoa:

• Wordfence Security. Suosituin WordPress-palomuuri. XML-RPC:n estämisen lisäksi se tarjoaa haittaohjelmaskannerin, kirjautumissuojauksen ja liikenteen seurannan. Wordfencen asetuksissa → Login Security → valitse "Disable XML-RPC authentication".

• Disable XML-RPC-API. Kevyt lisäosa, joka tekee täsmälleen yhden asian: koukuttaa xmlrpc_enabled-suodattimen ja poistaa päätepisteen käytöstä. Ei lisäasetuksia; aktivoi ja unohda.

• iThemes Security (Solid Security). Kattava lisäosa, jossa on WordPress Tweaks -moduuli, jossa XML-RPC poistetaan käytöstä yhdellä valintaruudulla. Se sulkee myös muita vektoreita: tietokannan etuliitteen vaihtaminen, tiedostoeditorin poistaminen käytöstä hallintapaneelista, brute force -suojaus.

Kun olet aktivoinut minkä tahansa näistä lisäosista, varmista aina, että xmlrpc.php palauttaa virheen, ei tervehdystä.

Tapa 4: palomuuritason esto (Cloudflare / Sucuri)

Tehokkain suojaustaso on verkkopalomuuri, joka hylkää haitalliset pyynnöt jo ennen kuin ne saavuttavat hosting-palvelusi.

Cloudflare** WAF.** Luo mukautettu sääntö: URI Path -kenttä sisältää xmlrpc.php → toiminto Block. Pyynnöt suodatetaan Cloudflaren verkkotasolla (yli 330 toimipistettä maailmanlaajuisesti); palvelimesi ei koskaan näe niitä. Ilmainen paketti sisältää 5 mukautettua sääntöä, mikä riittää. Bonus: Cloudflare näyttää estettyjen pyyntöjen tilastot, ja voit nähdä hyökkäyksen laajuuden omin silmin.

Sucuri Website Firewall. Samankaltainen lähestymistapa: WAF-sääntö URI:lle /xmlrpc.php. Sucuri tarjoaa myös tiedostojen eheyden valvonnan ja automaattisen haittaohjelmien puhdistuksen.

Palomuurisääntö toimii hyvin yhdistettynä .htaccess-tiedostoon tai ohjelmalliseen käytöstä poistamiseen: palomuuri katkaisee massaroskaliikenteen, kun taas paikallinen esto toimii varasuunnitelmana siltä varalta, että liikenne jotenkin ohittaa WAF:n.

Mitä tehdä, jos käytät Jetpackia

Automatticin Jetpack käyttää XML-RPC:tä linkittääkseen sivustosi WordPress.com-palvelimiin. Jos poistat xmlrpc.php-tiedoston kokonaan käytöstä, Jetpack lakkaa toimimasta: tilastot, tilaukset, kuva-CDN, Related Posts -moduuli ja Jetpackin brute force -suojaus kaikki hajoavat kerralla.

Ratkaisu: älä tapa XML-RPC:tä kokonaan, vaan salli valikoivasti pyynnöt Jetpack-palvelimilta:

• Jätä xmlrpc.php saavutettavaksi (ÄLÄ estä .htaccess-tiedoston kautta ja ÄLÄ koukuta xmlrpc_enabled-suodatinta).

• Määritä Cloudflare WAF näin: salli pyynnöt xmlrpc.php-tiedostoon VAIN Automatticin IP-alueista (lista päivitetään Jetpackin dokumentaatiossa), estä loput.

• Vähintäänkin poista RSD- ja WLW-otsakkeet käyttämällä menetelmän 2 koodinpätkää, jotta et paljasta päätepistettä <head>-osiossa tarpeettomasti.

• Asenna Wordfence ja ota käyttöön brute force -suojaus erityisesti xmlrpc.php-tiedostolle; se ei estä laillisia Jetpack-pyyntöjä, mutta katkaisee salasanan arvausyritykset.

⁉️🤔 Usein kysytyt kysymykset

Voinko vain poistaa xmlrpc.php-tiedoston palvelimelta?

Voit, mutta se on huono käytäntö. Seuraavassa WordPress-päivityksessä tiedosto palautuu, ja olet taas haavoittuvainen. On parempi estää pääsy .htaccess-tiedoston kautta tai poistaa toiminnallisuus käytöstä koodissa suodattimella: vaikutus on sama, mutta ydintiedostojen päivitykset eivät riko suojaustasi. Jos poistit tiedoston, muista poistaa rsd_link wp_head-kohdasta, muuten kävijät saavat 404-virheen seuratessaan EditURI-linkkiä.

Rikkooko XML-RPC:n poistaminen käytöstä WooCommercen?

Ei. WooCommerce on siirtynyt täysin WordPress REST API:iin, eikä se ole riippuvainen XML-RPC:stä. Kauppasi jatkaa toimintaansa ilman muutoksia. Ainoa poikkeus on, jos käytät jotakin ikivanhaa, XML-RPC:hen sidottua räätälöityä ratkaisua, mutta sellaisia ei käytännössä ole enää jäljellä.

Entä jos hosting-palveluntarjoajani estää jo xmlrpc.php:n?

Jos palveluntarjoaja on jo poistanut XML-RPC:n käytöstä palvelintasolla, sinun ei tarvitse tehdä mitään; päätepiste ei ole käytettävissä. Tarkista: avaa xmlrpc.php; jos näet 403-virheen, suojaus toimii. Ainoa lisäämisen arvoinen asia on RSD- ja WLW-otsakkeiden poistaminen functions.php-tiedoston kautta, koska palveluntarjoaja ei koske niihin.

Tarvitseeko minun poistaa XML-RPC käytöstä, jos olen hallitussa WordPress-hostingissa?

Useimmat hallitut palveluntarjoajat (Kinsta, WP Engine, SiteGround) estävät tai rajoittavat tiukasti xmlrpc.php-tiedostoa alustatasolla. Tarkista selaimella, onko päätepiste auki. Jos se on estetty, lisätoimia ei tarvita. Jos se on auki, lisää .htaccess-sääntö: hallitut palveluntarjoajat eivät korvaa sitä.

Mistä tiedän, hyökätäänkö sivustolleni xmlrpc.php:n kautta juuri nyt?

Kolme merkkiä: jyrkkä piikki palvelimen kuormituksessa liikenteen pysyessä ennallaan, sadat identtiset POST-pyynnöt xmlrpc.php-tiedostoon pääsylokeissa ja hosting-palveluntarjoajasi muisti-/suoritintehoraja-virheet. Ota seuranta käyttöön (Wordfence → Live Traffic tai Cloudflare → Security Events); näet hyökkäyksen lähteen ja laajuuden reaaliajassa.

Kannattaako xmlrpc.php poistaa käytöstä vuonna 2026

Lyhyt vastaus: kyllä, jos et käytä Jetpackia etkä julkaise artikkeleita WordPress-mobiilisovelluksen kautta.

XML-RPC on jäänne WordPress 1.5:n aikakaudelta. REST API on jo kauan sitten ottanut sen paikan, ja xmlrpc.php-tiedostosta itsestään on tullut avoin ovi brute force- ja DDoS-hyökkäyksille. Sen sulkeminen vie viisi minuuttia. Valitse tilanteeseesi sopiva menetelmä:

• Et halua koskea koodiin: asenna Disable XML-RPC-API, kaksi napsautusta.
• Sinulla on pääsy palvelimen tiedostoihin: lisää sääntö .htaccess-tiedostoon, palvelintaso on luotettavampi.
• Suosit puhdasta koodia: käytä xmlrpc_enabled-suodatinta ja poista otsakkeet kahdella koodinpätkällä functions.php-tiedostossa.
• Haluat maksimaalisen suojauksen: määritä WAF-sääntö Cloudflaressa ja yhdistä se paikalliseen estoon.

Estämisen jälkeen varmista aina, että xmlrpc.php palauttaa 403 Forbidden -virheen, ja seuraa lokeja vähintään viikon ajan; tulet yllättymään, kuinka paljon roskaliikennettä katoaa. Tilaa myös WordPress-päivitykset: historia osoittaa, että vanhat protokollat kuolevat hitaasti, ja uusia XML-RPC-haavoittuvuuksia saattaa ilmetä vielä vuoden 2026 jälkeenkin.