🔐 Sicurezza WordPress e il file xmlrpc.php: cos'è, perché è pericoloso e come disabilitarlo

Ogni sito WordPress conserva nella root un file «silenzioso» che la maggior parte dei proprietari scopre solo dopo un attacco. Si chiama xmlrpc.php. Il file in sé non è malevolo: WordPress avverte onestamente che si tratta di un’interfaccia per l’interazione remota. Ma è attraverso questo file che da anni i bot forzano password, inviano pingback di spam e generano traffico DDoS.

Secondo i dati Wordfence del 2024, gli attacchi via XML-RPC sono tra i primi cinque vettori di attacco contro i siti WordPress. Una singola richiesta system.multicall permette a un malintenzionato di testare centinaia di password in un colpo solo, invece di una sola come tramite il form di login. I provider di hosting registrano milioni di tentativi del genere ogni mese su un sito medio.

Cerchiamo di capire a cosa serve davvero questo file, chi dovrebbe tenerlo e, soprattutto, vediamo cinque modi per disabilitare o bloccare in sicurezza xmlrpc.php, da un plugin one-click a modifiche mirate su .htaccess.

💡 Panoramica rapida:

• Scopri cos’è xmlrpc.php e quali funzioni di WordPress dipendono da lui (pingback, app mobile, Jetpack)
• Valuta i rischi reali: amplificazione brute-force, DDoS via pingback e scansione delle directory da parte dei bot
• Scegli il metodo di protezione giusto: disabilitare via plugin, bloccare tramite .htaccess, chiudere l’accesso a livello di web server o rimuovere il file
• Imposta il monitoraggio: come assicurarsi che xmlrpc.php non risponda più alle richieste

Cos’è xmlrpc.php e quali funzioni di WordPress dipendono da lui

XML-RPC è un protocollo di chiamata di procedura remota che lavora su HTTP e trasmette dati in formato XML. La tecnologia è apparsa alla fine degli anni ’90, molto prima delle REST API, e WordPress l’ha ereditata agli albori. Il file xmlrpc.php nella root del sito accetta richieste XML, le elabora e restituisce una risposta, per esempio pubblica un articolo, carica un file media o verifica i permessi di un utente.

In pratica, diversi scenari passano attraverso xmlrpc.php:

• Pingback e trackback. Quando qualcuno linka un tuo articolo, il suo sito invia una richiesta XML-RPC con una notifica. Il tuo WordPress verifica il link e, se è reale, aggiunge il pingback ai commenti.

• Pubblicazione remota. Applicazioni come il vecchio Windows Live Writer o client desktop (TextMate, MarsEdit) usavano XML-RPC per scrivere e inviare articoli senza entrare nel pannello di amministrazione.

• App mobile di WordPress. L’app ufficiale per iOS e Android si è appoggiata a lungo su XML-RPC, anche se ora sta migrando sempre più verso le REST API.

• Integrazioni. Servizi come Jetpack (parte delle sue funzionalità), IFTTT e alcuni strumenti SEO usano ancora XML-RPC per connettersi al sito.

Con il rilascio delle REST API di WordPress nella versione 4.7 (dicembre 2016), la maggior parte delle integrazioni moderne è passata al nuovo protocollo. Le REST API sono più veloci, lavorano con JSON invece che con XML e sono meglio documentate. Ciononostante, WordPress include ancora xmlrpc.php in ogni installazione per retrocompatibilità.

Sfumatura importante: a partire da WordPress 2.6 (nel lontano 2008), la funzionalità di pubblicazione remota via XML-RPC è disabilitata di default. Per attivarla, bisogna spuntare esplicitamente la casella in «Impostazioni → Scrittura». Pingback e trackback continuano invece a funzionare.

Perché xmlrpc.php è pericoloso: tre vettori di attacco principali

Gli sviluppatori di WordPress hanno corretto xmlrpc.php più di una volta. Nella versione 2.1.2, un utente autenticato con ruolo «collaboratore» poteva pubblicare un articolo aggirando le restrizioni. Nella 2.3.1, fu scoperta una fuga di informazioni attraverso XML-RPC. Entrambe le falle furono chiuse rapidamente, ma il protocollo stesso è rimasto architetturalmente vulnerabile a tre classi di attacchi ancora attuali nel 2026.

Amplificazione brute-force via system.multicall

Il problema principale è il metodo system.multicall. Permette di impacchettare più chiamate wp.getUsersBlogs in una sola richiesta HTTP. Ogni chiamata verifica una coppia «login + password». Così, invece di un tentativo per richiesta, l’attaccante ne fa centinaia. Cloudflare ha registrato picchi di decine di migliaia di richieste del genere all’ora su un singolo sito.

Il normale form di login wp-login.php è limitato a un tentativo per volta ed è facilmente protetto da un plugin come Wordfence o Limit Login Attempts. xmlrpc.php aggira tutti questi limitatori perché lavora su un endpoint diverso.

DDoS via pingback

La funzionalità pingback è pensata come una notifica innocua. Ma un attaccante può inviare false richieste di pingback per conto di centinaia di siti, e il tuo server andrà a verificare ogni «link», caricando CPU, rete e database. Su scala sufficiente, il sito va offline. Sucuri nel suo report 2023 definisce gli attacchi pingback uno dei vettori DDoS più comuni contro WordPress.

Scansione delle directory da parte dei bot

I bot cercano xmlrpc.php non solo nella root ma anche in sottodirectory inventate come /2026/01/xmlrpc.php e /blog/xmlrpc.php. Ognuna di queste richieste restituisce un 404 e spreca risorse del server. Anche se l’attacco fallisce, decine di migliaia di richieste spazzatura rallentano il sito e intasano i log. In pratica, i proprietari vedono i grafici in cPanel entrare in zona rossa, e il motivo sono proprio i bot che scansionano xmlrpc.php.

5 Modi per disabilitare o mettere in sicurezza xmlrpc.php

Ecco cinque metodi, dal più semplice al più radicale. Scegli in base alla tua situazione: se usi l’app mobile, se ti servono i pingback, che hosting hai.

1. Disabilitare via plugin

La strada più sicura per chi non vuole toccare il codice. Installi un plugin e lui blocca l’accesso a xmlrpc.php a livello WordPress, prima che inizi l’elaborazione della richiesta.

Pro: non serve modificare .htaccess o functions.php, facile da riattivare. Contro: aggiunge un altro plugin al pannello di amministrazione, la protezione si rimuove alla disattivazione.

Un paio di opzioni collaudate:

• Disable XML-RPC, minimalista, un’azione: attivato e l’accesso è chiuso. Nessuna impostazione.
• Wordfence Security, firewall completo in cui disabilitare XML-RPC è solo una delle funzioni. Adatto se usi già Wordfence o prevedi di installarlo.

2. Bloccare via.htaccess

Se lavori su un server Apache, il file .htaccess nella root del sito ti permette di bloccare l’accesso prima che la richiesta raggiunga WordPress. Questo riduce il carico: Apache restituisce subito 403 Forbidden, senza eseguire PHP.

Aggiungi il blocco seguente a .htaccess all’inizio del file, prima di # BEGIN WordPress:

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

La direttiva RedirectMatch 403 intercetta qualsiasi URL che termina con /xmlrpc.php, incluse sottodirectory come /2025/06/xmlrpc.php, e restituisce immediatamente 403.

Pro: non tocca il codice di WordPress, lavora prima che PHP venga caricato, risparmia risorse. Contro: bisogna modificare .htaccess manualmente, quando si cambia hosting o tema il file potrebbe essere sovrascritto.

Importante: prima di modificare .htaccess, fai un backup. Un errore di sintassi in .htaccess può mandare offline il sito (500 Internal Server Error).

3. Rimuovere i link via functions.php

Questo metodo non blocca il file in sé ma rimuove i link HTML a xmlrpc.php e wlwmanifest.xml dalla sezione <head> del sito. Il vantaggio è una visibilità ridotta: i bot che analizzano l’HTML non vedono un puntatore diretto all’endpoint XML-RPC.

Aggiungi al functions.php del tema attivo (o tramite il plugin Code Snippets):

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

L’hook rsd_link produce <link rel="EditURI">, un link a xmlrpc.php per i client Really Simple Discovery. L’hook wlwmanifest_link è per Windows Live Writer (non più supportato da tempo, ma WordPress lo produce ancora).

Pro: <head> pulito senza link spazzatura. Contro: xmlrpc.php rimane fisicamente accessibile via URL diretto, questa non è un blocco ma un mascheramento.

4. Chiudere l’accesso via WAF o Cloudflare

Un Web Application Firewall blocca le richieste a xmlrpc.php prima che raggiungano il tuo server. Questo è l’approccio più efficace per siti su qualsiasi hosting.

Opzioni di configurazione:

• Cloudflare (piano gratuito): WAF Rule → Block → campo URI Path contiene /xmlrpc.php. La richiesta viene respinta a livello di rete Cloudflare, il tuo server non la vede nemmeno.
• Wordfence WAF: Funzione integrata «Disabilita XML-RPC» nella sezione firewall.
• WAF dell’hosting: Kinsta, WP Engine e altri hoster gestiti permettono di disabilitare XML-RPC in un paio di click dal pannello di controllo.

Pro: zero carico sul server, si può regolare con precisione (per esempio, permettere Jetpack bloccando tutto il resto). Contro: richiede configurazione lato WAF, non tutti i provider di hosting offrono questa possibilità.

5. Rimuovere o rinominare il file stesso

Il metodo più radicale. Cancelli (o rinomini) il file xmlrpc.php dal server. Se il file non esiste fisicamente, non c’è nulla che elabori le richieste, il server restituisce 404.

Sfumatura importante: al prossimo aggiornamento di WordPress, il file verrà ripristinato. Gli aggiornamenti automatici del core sovrascrivono tutti i file di WordPress, incluso xmlrpc.php. Quindi la cancellazione è una misura temporanea, a meno che non si imposti una pulizia regolare.

Se scegli questa strada, affianca alla cancellazione la regola .htaccess del metodo 2. Senza, i bot continueranno a bussare all’URL xmlrpc.php e il server restituirà onestamente 404 a ogni richiesta, migliaia di errori nei log.

Vale la pena disabilitare xmlrpc.php?

La risposta dipende da cosa usi. Scorri la checklist:

Se non usi una vecchia versione dell’app mobile, non hai attivato la gestione Jetpack con WordPress.com e i pingback non sono critici per te, disabilitalo senza esitare. Nel 2026, le REST API coprono quasi tutti gli scenari reali.

Video: come disabilitare XML-RPC in WordPress in 5 minuti

Guarda una guida visiva per disabilitare xmlrpc.php, con dimostrazione a schermo e spiegazione di ciascun metodo:

⁉️🤔 Domande frequenti

È sicuro ignorare semplicemente xmlrpc.php?

Nella maggior parte dei casi, no. Anche se non usi XML-RPC, i bot scansionano costantemente questo endpoint. Ogni richiesta del genere carica il server. Meglio chiudere esplicitamente l’accesso via .htaccess o plugin, questo elimina sia il rischio brute-force sia le richieste spazzatura nei log.

Il sito si rompe se xmlrpc.php viene disabilitato?

WordPress in sé continuerà a funzionare senza cambiamenti. Verifica solo se stai usando la gestione Jetpack con WordPress.com o una vecchia versione dell’app mobile. Se no, disabilita senza preoccupazioni. I pingback smetteranno di arrivare, ma la maggior parte dei siti non li usa comunque per una comunicazione reale.

Come verificare che xmlrpc.php sia effettivamente bloccato?

Apri nel tuo browser https://your-site.com/xmlrpc.php. Se vedi una schermata bianca con il messaggio «XML-RPC server accepts POST requests only», il file è vivo e risponde. Se ottieni 403 Forbidden o 404 Not Found, il blocco funziona. Per un monitoraggio automatico, puoi usare checker online come xmlrpc.eror.xyz o una richiesta curl dalla console.

Cosa è meglio: plugin o.htaccess?

.htaccess blocca la richiesta prima che WordPress si avvii, questo fa risparmiare risorse del server. Un plugin è più facile da installare e non richiede di modificare file. Per siti non critici non c’è quasi differenza. Per progetti ad alto carico, .htaccess o una regola WAF sono preferibili.

Devo aggiornare WordPress dopo aver disabilitato xmlrpc.php?

No. Disabilitare xmlrpc.php non dipende dalla versione di WordPress e non influisce sugli aggiornamenti del core. Unica sfumatura: se hai cancellato fisicamente il file, l’aggiornamento lo ripristinerà, rendendo necessaria una nuova cancellazione.

Quindi cosa fare con xmlrpc.php sul tuo sito?

Non esiste una risposta universale, è il contesto a decidere tutto. Ma la pratica di migliaia di siti WordPress dà un quadro chiaro: se non sai se ti serve XML-RPC, non ti serve.

Vuoi affidabilità senza mettere mano al codice, installa Disable XML-RPC. Sei pronto a dedicare cinque minuti a .htaccess, ottieni una protezione a livello server senza plugin aggiuntivi. Usi Cloudflare, imposta una regola WAF e dimentica il problema.

La cosa principale è non lasciare xmlrpc.php aperto «per default». Nel 2026, ogni endpoint WordPress non chiuso è un bersaglio per bot automatizzati che non si curano se hai un blog o un negozio online. Chiudi l’accesso usando uno dei metodi sopra, verifica il risultato con una richiesta curl e dormi sonni tranquilli.