Il tuo sito è lento, il provider di hosting ti invia avvisi di limiti superati e i log mostrano un flusso infinito di richieste POST a xmlrpc.php. Se amministri WordPress, questo incubo ti sarà probabilmente familiare.

Il file xmlrpc.php è un elemento silenzioso ma estremamente pericoloso di qualsiasi installazione WordPress. Risiede nella root del tuo sito dall'installazione del CMS ed è rimasto per decenni un punto d'accesso privilegiato per bot e aggressori. Secondo il report Wordfence 2024, gli attacchi XML-RPC sono tra i primi cinque vettori di minaccia per i siti WordPress, e nel 2026 non è cambiato nulla.

Eppure la maggior parte dei proprietari di siti non ha idea del perché questo file esista o di come neutralizzarlo. Questa guida illustra quattro metodi funzionanti per bloccare xmlrpc.php, da una rapida regola .htaccess a un firewall a livello di CDN. Niente fronzoli, solo codice testato e spiegazioni su quando usare ciascun metodo.

💡 Panoramica rapida:

• Verifica se il tuo xmlrpc.php risponde alle richieste POST (probabilmente sì)
• Scegli un metodo di blocco: htaccess, codice in functions.php, plugin o WAF
• Aggiungi la regola di blocco e verifica che l'endpoint restituisca 403 Forbidden
• Se usi Jetpack, configura una protezione firewall mirata invece di disabilitarlo completamente

Cos'è xmlrpc.php e perché è ancora in WordPress

XML-RPC (Remote Procedure Call) è un protocollo che consente ad applicazioni esterne di comunicare con WordPress. Fu aggiunto al core nella versione 1.5 e per decenni è stata l'unica API per la pubblicazione remota: le app mobile di WordPress, i client desktop come Windows Live Writer e i servizi di terze parti dipendevano tutti da esso.

Con il rilascio della REST API di WordPress nella versione 4.7 (2016), la necessità di XML-RPC è in gran parte scomparsa. La moderna REST API copre tutto ciò che XML-RPC faceva, e lo fa in modo più sicuro, più veloce e con un'autenticazione corretta tramite nonce o OAuth.

Ma il file xmlrpc.php è ancora presente nella root di ogni installazione WordPress. La pubblicazione remota tramite esso è disabilitata di default, eppure l'endpoint accetta richieste. Basta aprire yoursite.com/xmlrpc.php in un browser per vedere: "XML-RPC server accepts POST requests only". Questo significa che l'endpoint è attivo e pronto per essere attaccato.

Perché xmlrpc.php è pericoloso: principali vettori d'attacco

Gli aggressori usano xmlrpc.php per due tipi principali di attacchi, ed entrambi possono mandare offline il tuo sito.

Brute force tramite system.multicall. Il metodo system.multicall consente di impacchettare centinaia di tentativi di autenticazione in UNA singola richiesta HTTP. Invece di testare le password una alla volta (come avviene tramite wp-login.php), un bot invia un array di login e password tutti insieme. I plugin standard di limitazione dei login non rilevano tali richieste, per loro sembra "un solo tentativo". Risultato: gli aggressori provano migliaia di combinazioni in pochi secondi senza far scattare alcun blocco.

DDoS via Pingback. La funzione pingback consente a un altro sito di notificare al tuo WordPress un link verso di esso. Un aggressore invia una richiesta pingback falsificata, sostituendo l'indirizzo IP della vittima come "mittente". Il tuo server si attiva diligentemente per verificare il link e attacca un host di destinazione ignaro. Moltiplica questo per migliaia di installazioni WordPress compromesse e ottieni un attacco DDoS distribuito in cui il tuo sito funge da carne da cannone.

I provider di hosting monitorano il traffico in uscita di questo tipo e possono congelare il tuo account per "partecipazione a DDoS". Nel frattempo, il tuo server spreca CPU, memoria e larghezza di banda per servire richieste spazzatura.

Verifica: il tuo xmlrpc.php risponde

Prima di bloccare, assicurati che l'endpoint sia effettivamente aperto. Apri questo nel tuo browser:

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

Se vedi la stringa "XML-RPC server accepts POST requests only", l'endpoint è attivo e gli aggressori possono inviargli richieste. Se ricevi 403 Forbidden o 404, la protezione sta già funzionando.

Secondo metodo: invia una richiesta POST di test via terminale:

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

Una risposta con 200 OK e una struttura XML conferma: XML-RPC accetta richieste ed è pronto per essere sfruttato.

Metodo 1: blocco rapido via.htaccess

Il metodo più semplice ed efficace è bloccare l'accesso al file a livello di server web. La richiesta viene respinta prima di raggiungere WordPress, il che fa risparmiare risorse del server e funziona anche se il sito è sotto carico.

Aggiungi questo al tuo .htaccess root (quello accanto a wp-config.php):

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

La direttiva Require all denied è sintassi Apache 2.4+, attuale per tutti i moderni provider di hosting. Dopo aver salvato, apri xmlrpc.php nel browser; dovresti ottenere 403 Forbidden.

Se il tuo server esegue nginx, aggiungi la regola alla configurazione del virtual host:

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

Dopo aver modificato la configurazione di nginx, ricordati di ricaricare il server: sudo nginx -s reload.

Questo metodo funziona se NON hai DEFINITIVAMENTE bisogno di XML-RPC, né per Jetpack, né per le app mobile di WordPress, né per integrazioni WooCommerce.

Metodo 2: disabilitazione via functions.php (metodo programmatico)

Se preferisci risolvere il problema a livello di codice anziché di configurazioni server, ecco due snippet testati per il functions.php del tuo tema attivo o Code Snippets.

Disabilitazione completa di XML-RPC (WP 3.5+):

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

Una riga, e WordPress smette di elaborare qualsiasi richiesta XML-RPC. Quando si tenta di accedere a xmlrpc.php, il client riceve una risposta di errore; il file stesso rimane sul server ma è funzionalmente morto.

Pulizia degli header wp_head dai link RSD e WLW:

Anche dopo aver disabilitato XML-RPC WordPress continua a inserire due righe in <head> che rivelano informazioni sul tuo sito:

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

Gli hook rsd_link e wlwmanifest_link aggiungono i tag <link rel="EditURI"> e <link rel="wlwmanifest"> a <head>; questi esistono esclusivamente per i client XML-RPC e non servono a nessuno scopo pratico nel 2026. Rimuovili.

⚠️ Importante: le modifiche al functions.php del tema andranno perse con l'aggiornamento. Usa un tema child o il plugin Code Snippets per l'archiviazione permanente del codice personalizzato.

Metodo 3: plugin di sicurezza

Se non vuoi toccare codice, installa un plugin. Tre opzioni testate:

• Wordfence Security. Il firewall WordPress più diffuso. Oltre a bloccare XML-RPC, fornisce uno scanner malware, protezione del login e monitoraggio del traffico. In Impostazioni Wordfence → Sicurezza Login → seleziona "Disabilita autenticazione XML-RPC".

• Disable XML-RPC-API. Un plugin leggero che fa esattamente una cosa: aggancia il filtro xmlrpc_enabled e disabilita l'endpoint. Nessuna impostazione aggiuntiva; attiva e dimentica.

• iThemes Security (Solid Security). Un plugin completo con un modulo WordPress Tweaks dove XML-RPC viene disabilitato con un singolo checkbox. Chiude anche altri vettori: modifica del prefisso delle tabelle, disabilitazione dell'editor file da admin, protezione brute force.

Dopo aver attivato uno qualsiasi di questi plugin, verifica sempre che xmlrpc.php restituisca un errore, non un messaggio di benvenuto.

Metodo 4: blocco a livello di firewall (Cloudflare / Sucuri)

Il livello di protezione più potente è un firewall web che scarta le richieste malevole prima ancora che raggiungano il tuo hosting.

Cloudflare** WAF.** Crea una regola personalizzata: campo URI Path contiene xmlrpc.php → azione Block. Le richieste vengono filtrate a livello di rete Cloudflare (oltre 330 punti di presenza nel mondo); il tuo server non le vede mai. Il piano Free include 5 regole personalizzate, il che è sufficiente. Bonus: Cloudflare mostra le statistiche delle richieste bloccate e puoi vedere la portata dell'attacco con i tuoi occhi.

Sucuri Website Firewall. Approccio simile: una regola WAF sull'URI /xmlrpc.php. Sucuri offre anche monitoraggio dell'integrità dei file e pulizia automatica del malware.

Una regola firewall funziona bene in combinazione con .htaccess o la disabilitazione programmatica: il firewall taglia il grosso della spazzatura, mentre il blocco locale funge da riserva nel caso in cui il traffico bypassi in qualche modo il WAF.

Cosa fare se usi Jetpack

Jetpack di Automattic utilizza XML-RPC per collegare il tuo sito con i server di WordPress.com. Se disabiliti completamente xmlrpc.php, Jetpack smette di funzionare: statistiche, abbonamenti, CDN delle immagini, il modulo Post Correlati e la protezione brute force di Jetpack si rompono tutti insieme.

La soluzione: non eliminare del tutto XML-RPC, ma consentire selettivamente le richieste dai server Jetpack:

• Lascia xmlrpc.php accessibile (NON bloccare via .htaccess e NON agganciare il filtro xmlrpc_enabled).

• Configura il WAF di Cloudflare in questo modo: consenti le richieste a xmlrpc.php SOLO dagli intervalli IP di Automattic (l'elenco è aggiornato nella documentazione Jetpack), blocca il resto.

• Come minimo, rimuovi gli header RSD e WLW usando lo snippet del metodo 2, così da non esporre inutilmente l'endpoint in <head>.

• Installa Wordfence e abilita la protezione brute force specificamente per xmlrpc.php; non blocca le richieste legittime di Jetpack ma stronca i tentativi di indovinare la password.

⁉️🤔 Domande frequenti

Posso semplicemente eliminare il file xmlrpc.php dal server?

Puoi, ma è una cattiva pratica. Al prossimo aggiornamento di WordPress, il file verrà ripristinato e sarai di nuovo vulnerabile. È meglio bloccare l'accesso via .htaccess o disabilitare la funzionalità con un filtro nel codice: l'effetto è lo stesso, ma gli aggiornamenti del core non romperanno la tua protezione. Se hai già eliminato il file, assicurati di rimuovere rsd_link da wp_head, altrimenti i visitatori riceveranno un 404 quando seguono il link EditURI.

Disabilitare XML-RPC romperà WooCommerce?

No. WooCommerce è passato completamente alla REST API di WordPress e non dipende da XML-RPC. Il tuo negozio continuerà a funzionare senza modifiche. L'unica eccezione è se usi una vecchia soluzione personalizzata legata a XML-RPC, ma praticamente non ne rimane nessuna.

Cosa succede se il mio provider di hosting blocca già xmlrpc.php?

Se il provider ha già disabilitato XML-RPC a livello di server, non devi fare nulla; l'endpoint è inaccessibile. Verifica: apri xmlrpc.php; se vedi 403, la protezione funziona. L'unica cosa che vale la pena aggiungere è la rimozione degli header RSD e WLW via functions.php, perché il provider non li tocca.

Devo disabilitare XML-RPC se sono su un hosting WordPress gestito?

La maggior parte degli host gestiti (Kinsta, WP Engine, SiteGround) blocca o limita rigorosamente xmlrpc.php a livello di piattaforma. Verifica se l'endpoint è aperto via browser. Se bloccato, non è richiesta alcuna azione aggiuntiva. Se aperto, aggiungi la regola .htaccess: gli host gestiti non la sovrascrivono.

Come faccio a sapere se il mio sito è sotto attacco tramite xmlrpc.php in questo momento?

Tre segnali: un picco improvviso del carico del server a traffico invariato, centinaia di richieste POST identiche a xmlrpc.php nei log di accesso ed errori di limite memoria/CPU dal tuo provider di hosting. Attiva il monitoraggio (Wordfence → Live Traffic o Cloudflare → Security Events); vedrai la fonte e la portata dell'attacco in tempo reale.

Vale la pena disabilitare xmlrpc.php nel 2026

Risposta breve: sì, se non usi Jetpack e non pubblichi articoli tramite l'app mobile di WordPress.

XML-RPC è un retaggio dell'era di WordPress 1.5. La REST API ha preso da tempo il suo posto e xmlrpc.php stesso è diventato una porta aperta per attacchi brute force e DDoS. Chiuderla richiede cinque minuti. Scegli il metodo adatto alla tua situazione:

• Non vuoi toccare codice: installa Disable XML-RPC-API, due click.
• Hai accesso ai file del server: aggiungi una regola a .htaccess, il livello server è più affidabile.
• Preferisci codice pulito: applica il filtro xmlrpc_enabled e rimuovi gli header con due snippet in functions.php.
• Vuoi la massima protezione: imposta una regola WAF in Cloudflare e combinala con un blocco locale.

Dopo il blocco, verifica sempre che xmlrpc.php restituisca 403 Forbidden e monitora i log per almeno una settimana; sarai sorpreso di quanto traffico spazzatura scompare. Iscriviti anche agli aggiornamenti di WordPress: la storia mostra che i vecchi protocolli muoiono lentamente e nuove vulnerabilità XML-RPC potrebbero emergere anche dopo il 2026.