Se hai trovato richieste verso xmlrpc.php nei log del server, un plugin di sicurezza ti ha consigliato di bloccarlo oppure hai letto che questa funzione di WordPress è pericolosa, la domanda giusta non è semplicemente “come la disattivo?”.
La domanda è: il tuo sito utilizza ancora XML-RPC?
Si tratta di un sistema di comunicazione remota ancora presente nel core. Attraverso il file xmlrpc.php, software e servizi esterni possono eseguire determinate operazioni sul sito senza passare dal normale pannello di amministrazione.
Il problema è che lo stesso endpoint è anche un bersaglio frequente del traffico automatizzato e dei tentativi di brute force. Per questo, se non lo utilizzi ha senso impedirne l’accesso; se invece un servizio come Jetpack o un’altra integrazione ne dipende, bloccarlo completamente può interrompere funzionalità legittime.
In questa guida vedremo cosa fa realmente xmlrpc.php, come capire se è attivo, quali rischi comporta, cosa cambia rispetto alle REST API e soprattutto come scegliere tra blocco completo, limitazione dei metodi e protezione tramite firewall.
Cos’è XML-RPC in WordPress e cosa fa xmlrpc.php
XML-RPC significa XML Remote Procedure Call. È un protocollo che permette a un programma di chiedere a un sistema remoto di eseguire determinate operazioni inviando richieste attraverso HTTP e rappresentando i dati in XML.
Nel caso di WordPress, il punto di ingresso è normalmente:
https://tuodominio.it/xmlrpc.php
Il server integrato in WordPress espone diversi metodi utilizzabili per operazioni come la gestione remota di contenuti, commenti, opzioni e pingback.
Il principio è diverso da quello di una normale visita al sito. Un browser apre una pagina e riceve HTML; un client remoto invia invece una richiesta strutturata all’endpoint, specificando il metodo da eseguire e gli eventuali parametri necessari.
Come funziona l’endpoint /xmlrpc.php
Immagina un’applicazione esterna che debba pubblicare un articolo sul tuo WordPress.
Il flusso, semplificando, è questo:
client remoto → richiesta HTTP POST → xmlrpc.php → server WordPress → metodo richiesto → risposta XML
Per le operazioni che richiedono permessi, WordPress deve anche autenticare l’utente prima di eseguire l’azione.
Questo è il motivo per cui xmlrpc.php non è semplicemente “un vecchio file presente nella root”. È un endpoint applicativo che espone funzioni precise del CMS.
Quali operazioni può eseguire un client remoto
WordPress mantiene compatibilità con diverse famiglie di metodi. Il server implementa, tra gli altri, le proprie API e interfacce storiche come Blogger, MetaWeblog e MovableType, oltre ai pingback.
Un’integrazione può quindi leggere o modificare contenuti, gestire alcune informazioni del sito oppure comunicare attraverso specifiche funzioni esposte dal server.
Questo non significa che chiunque possa modificare il tuo sito semplicemente chiamando xmlrpc.php: le operazioni protette richiedono autenticazione e autorizzazione.
La superficie resta comunque interessante dal punto di vista della sicurezza, perché un endpoint pubblico può ricevere grandi quantità di richieste anche quando il sito non lo utilizza realmente.
XML-RPC serve ancora su WordPress?
Per molti siti moderni la risposta è no, ma non è una regola universale.
Le WordPress REST API sono oggi l’interfaccia più naturale per moltissime integrazioni e utilizzano JSON invece del formato XML del protocollo storico.
Questo, però, non significa che quest’ultimo sia stato eliminato dal CMS.
È ancora presente nel core e alcune applicazioni o servizi continuano a farne uso. La scelta corretta non consiste quindi nel considerarlo automaticamente obsoleto, ma nel verificare se esiste una dipendenza concreta sul tuo sito.
Jetpack, app e integrazioni che possono dipendere dall’endpoint
Jetpack è il caso più importante da controllare.
La sua documentazione indica ancora xmlrpc.php tra i componenti necessari alla comunicazione tra il sito e i servizi WordPress.com. Un blocco server, una regola WAF troppo restrittiva o un plugin che impedisce l’accesso al file possono quindi provocare errori di connessione.
Per questo non consiglio di bloccare l’endpoint alla cieca su un sito che utilizza Jetpack.
Lo stesso criterio vale per client di pubblicazione, automazioni o sistemi legacy: prima di chiuderlo verifica se esiste realmente un servizio che lo sta chiamando.
REST API e Application Passwords: cosa è cambiato
Il fatto che il protocollo sia una tecnologia storica non significa che l’autenticazione debba necessariamente dipendere dalla password principale dell’utente.
WordPress mette a disposizione le Application Passwords, credenziali separate create per l’accesso programmatico.
Ogni Application Password può essere assegnata a una specifica integrazione e successivamente revocata senza modificare la password principale dell’account.
WordPress ne prevede l’utilizzo per le API, comprese le REST API e, quando questa interfaccia remota è disponibile, anche per XML-RPC.
È una distinzione importante: oggi non è corretto ridurre il problema a “username e password normali”. L’autenticazione disponibile è più articolata e la scelta dipende dal client utilizzato.
XML-RPC è un rischio per la sicurezza?
La presenza dell’endpoint non dimostra di per sé che un sito sia vulnerabile o compromesso. Rappresenta però una superficie pubblica che viene frequentemente presa di mira dal traffico automatizzato.
La stessa documentazione WordPress dedicata agli attacchi brute force indica xmlrpc.php come un bersaglio frequente e suggerisce di disabilitarlo quando non viene utilizzato oppure di limitarne l’accesso quando è necessario.
La domanda utile, quindi, non è se il protocollo sia “sicuro” o “pericoloso” in assoluto. Conta quali funzioni lasci accessibili, come proteggi le richieste e se il sito ha realmente bisogno dell’endpoint.
Brute force e system.multicall: cosa conta davvero
Un normale attacco brute force tenta molte combinazioni di credenziali alla ricerca di quelle corrette.
Questa interfaccia può essere interessante per lo stesso tipo di attività perché espone metodi autenticati e comprende funzionalità come system.multicall, che consentono di aggregare più chiamate all’interno della comunicazione.
Per il proprietario del sito la conseguenza pratica è semplice: proteggere soltanto la schermata wp-login.php non significa automaticamente aver controllato ogni possibile percorso di autenticazione.
Se il sito non utilizza questo canale remoto, bloccarne l’accesso elimina alla radice quella specifica superficie. Se invece è necessario, diventa più sensato applicare rate limiting, filtri WAF e controllo dei log.
Un Web Application Firewall può intervenire prima che una richiesta indesiderata raggiunga la logica applicativa di WordPress ed è quindi particolarmente utile quando il file deve restare raggiungibile.
Pingback.ping e abuso delle richieste
Tra i metodi esposti dal server WordPress troviamo anche pingback.ping.
I pingback sono nati per consentire a un sito di notificare automaticamente un altro sito quando viene citato attraverso un link. Il sistema può però essere utilizzato impropriamente per indurre installazioni WordPress a effettuare richieste verso URL indicati da terzi.
Questo non significa che ogni pingback sia un attacco. Significa che, se non utilizzi la funzione, lasciare il metodo disponibile offre poco valore e mantiene una superficie che potresti non avere motivo di esporre.
È inoltre possibile rimuovere soltanto i metodi di pingback senza spegnere l’intera interfaccia remota, come vedremo tra poco.
Cosa cambia nei siti di staging e sviluppo
Nelle versioni recenti di WordPress esiste anche una gestione più consapevole dei ping in base al tipo di ambiente.
La funzione wp_should_disable_pings_for_environment() determina se pingback, trackback e notifiche ping debbano essere disattivati. Il comportamento predefinito è più restrittivo negli ambienti classificati come local, development o staging.
Questo dettaglio è utile soprattutto per chi gestisce infrastrutture con ambienti separati: un sito di staging non dovrebbe normalmente iniziare a inviare notifiche o ricevere ping come se fosse la versione pubblica.
Come verificare se xmlrpc.php è attivo e se ti serve
Prima di modificare configurazioni, plugin o regole server, fai due controlli distinti:
- verifica se l’endpoint è raggiungibile;
- verifica se qualche servizio del sito ne dipende.
Sono due domande diverse. Un endpoint raggiungibile potrebbe non essere utilizzato da nessuno; al contrario, un endpoint bloccato potrebbe spiegare perché Jetpack o una vecchia integrazione non funziona più.
Cosa significa “XML-RPC server accepts POST requests only”
Il controllo più semplice consiste nell’aprire nel browser:
https://tuodominio.it/xmlrpc.php
Su una configurazione WordPress in cui la richiesta raggiunge normalmente il componente remoto puoi ricevere il messaggio:
XML-RPC server accepts POST requests only.
È normale: stai facendo una richiesta tramite browser, mentre il server si aspetta richieste POST.
Anche la documentazione di troubleshooting di Jetpack utilizza questo controllo per verificare la raggiungibilità dell’endpoint.
Il risultato va però interpretato correttamente:
- il messaggio relativo alle richieste POST indica che
xmlrpc.phpè raggiungibile; - un
403 Forbiddenpuò indicare un blocco applicato da server, firewall o hosting; - un
404 Not Foundpuò derivare da una regola di sicurezza o da una configurazione particolare; - una risposta positiva non dimostra che tutti i metodi siano disponibili.
Il test del browser serve quindi per un primo controllo, non per mappare tutte le funzioni esposte.
Controlla Jetpack, integrazioni e log prima di bloccarlo
Il secondo controllo è più importante del primo.
Prima di intervenire chiediti:
- utilizzo Jetpack?
- esistono applicazioni o servizi che pubblicano contenuti da remoto?
- utilizzo automazioni che dichiarano di collegarsi attraverso questo protocollo?
- nei log del server vedo richieste legittime verso
xmlrpc.phpoltre al traffico dei bot? - l’hosting applica già restrizioni specifiche all’endpoint?
Se non trovi alcuna dipendenza e il sito utilizza esclusivamente WordPress tramite browser e integrazioni moderne, il blocco completo può essere la soluzione più semplice.
Se invece trovi traffico legittimo, conviene capire quali metodi servono prima di chiudere tutto.
Come disabilitare o limitare XML-RPC in WordPress
Qui è importante distinguere soluzioni che spesso vengono presentate come equivalenti, ma non lo sono.
Puoi:
- impedire completamente l’accesso a
xmlrpc.php; - disabilitare i metodi che richiedono autenticazione;
- rimuovere soltanto determinate funzioni;
- lasciare l’endpoint funzionante e limitare le richieste tramite server o WAF.
Scegliere il livello corretto è più importante del codice utilizzato.
Prima di modificare file server o PHP, esegui un backup e prova l’intervento in staging quando possibile.
Bloccare completamente xmlrpc.php a livello server o WAF
Se hai verificato che nessuna funzione del sito utilizza l’endpoint, bloccare direttamente l’accesso al file è il metodo più netto.
Su un server Apache compatibile con direttive .htaccess, una configurazione moderna può essere:
<Files "xmlrpc.php">
Require all denied
</Files>
In questo caso le richieste al file vengono fermate dal web server prima di arrivare alla normale esecuzione di WordPress.
Non usare questa regola se Jetpack o altre integrazioni devono raggiungere il file.
Su Nginx la configurazione equivalente deve essere applicata nella configurazione del server, per esempio:
location = /xmlrpc.php {
deny all;
}
Su hosting gestiti potresti non avere accesso diretto a queste configurazioni. In quel caso è preferibile utilizzare gli strumenti messi a disposizione dal provider oppure una regola del firewall.
Se il servizio remoto serve ancora, invece di una regola Block globale puoi valutare rate limiting e controlli mirati sul percorso /xmlrpc.php.
Cosa disabilita davvero il filtro xmlrpc_enabled
Una delle soluzioni più citate online è:
add_filter( 'xmlrpc_enabled', '__return_false' );
Il codice è valido, ma non significa “disabilita completamente xmlrpc.php”.
La documentazione ufficiale del filtro xmlrpc_enabled è molto esplicita: il filtro controlla i metodi che richiedono autenticazione. Non controlla invece i pingback e non rappresenta un interruttore globale per ogni funzione possibile.
Quindi:
xmlrpc_enabled = false ≠ blocco completo di /xmlrpc.php
È una differenza importante soprattutto quando l’obiettivo dell’intervento è ridurre l’esposizione dell’endpoint.
Se utilizzi questo filtro, inseriscilo preferibilmente in un piccolo plugin personalizzato, in un must-use plugin oppure attraverso uno strumento affidabile per gli snippet. Eviterei di legare una configurazione di sicurezza al functions.php di un tema che potrebbe essere sostituito o cambiato.
Rimuovere singoli metodi con xmlrpc_methods
WordPress espone anche il filtro xmlrpc_methods, che permette di modificare l’elenco dei metodi disponibili.
Per esempio, se vuoi eliminare quelli relativi ai pingback lasciando inalterate altre parti del servizio:
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );
Questo approccio è interessante quando non vuoi trattare il servizio come un interruttore acceso/spento, ma ridurre la superficie esposta conservando una funzione legittima.
Naturalmente devi sapere quali metodi utilizza l’integrazione che vuoi mantenere. Rimuoverli senza test può interromperla tanto quanto un blocco completo.
Plugin di sicurezza: quando hanno senso
Un plugin può essere la soluzione più semplice quando non vuoi intervenire direttamente sulle configurazioni del server.
Il criterio, però, non dovrebbe essere “installo un plugin solo perché contiene il pulsante Disable XML-RPC”.
Prima controlla se il plugin di sicurezza che utilizzi già gestisce:
- accesso all’endpoint;
- brute force;
- rate limiting;
- blocchi per percorso;
- logging delle richieste;
- regole firewall.
Aggiungere un secondo plugin per una sola impostazione può essere inutile se la stessa funzione è già disponibile nel tuo stack.
Il punto non è avere più strumenti, ma applicare il controllo nel livello più efficace e facile da mantenere.
Quale metodo scegliere per gestire XML-RPC
La decisione può essere riassunta così:
| Scenario | Scelta consigliata | Metodo | Attenzione |
|---|---|---|---|
| Non utilizzi servizi che dipendono dall’endpoint | Bloccalo | Server, hosting o WAF | Verifica prima eventuali integrazioni |
| Utilizzi Jetpack o un client che lo richiede | Mantienilo accessibile | WAF + rate limiting | Un blocco globale può interrompere la connessione |
| Vuoi impedire le operazioni autenticate | Disabilita i metodi autenticati | xmlrpc_enabled | Non blocca l’intero endpoint |
| Non usi i pingback ma ti servono altre funzioni | Rimuovi i metodi inutili | xmlrpc_methods | Testa l’integrazione dopo la modifica |
| Vedi molte richieste automatiche ma il servizio serve | Limita il traffico | WAF/server | Evita regole troppo aggressive |
| Non sai se viene utilizzato | Non bloccare ancora | Endpoint, log e test | Prima identifica le dipendenze |
La scelta che farei su un normale sito aziendale WordPress senza Jetpack, client remoti o integrazioni legacy è bloccare direttamente l’endpoint.
Su un sito che lo utilizza realmente, invece, preferirei ridurre ciò che è esposto e filtrare il traffico, anziché applicare una disattivazione globale e scoprire in seguito che una funzione importante ha smesso di comunicare.
Cosa può smettere di funzionare se blocchi XML-RPC
Il rischio operativo più comune non riguarda WordPress stesso.
Il frontend continuerà normalmente a mostrare pagine e articoli, il pannello wp-admin continuerà a funzionare e le REST API non scompaiono perché hai bloccato questo endpoint.
Il problema riguarda i sistemi che comunicano specificamente attraverso quel canale.
Potrebbero quindi smettere di funzionare:
- la connessione di Jetpack;
- client remoti che utilizzano il protocollo;
- vecchi software di pubblicazione;
- automazioni costruite esplicitamente su questa interfaccia;
- plugin o integrazioni personalizzate che chiamano i relativi metodi.
Per questo il controllo delle dipendenze viene prima del blocco.
Se dopo una modifica Jetpack perde la connessione oppure un’integrazione smette di pubblicare, il primo controllo da fare è verificare se /xmlrpc.php è diventato irraggiungibile.
XML-RPC e SEO: disabilitarlo migliora il posizionamento?
No: disabilitare XML-RPC non è una tecnica SEO e non esiste un vantaggio diretto di ranking documentato derivante dal semplice blocco di xmlrpc.php.
È importante separare sicurezza e SEO.
Un endpoint sottoposto a traffico abusivo può consumare risorse del server. Se il fenomeno diventa abbastanza grave da causare sovraccarichi, errori o indisponibilità del sito, hai un problema concreto di infrastruttura e user experience. Risolverlo è ovviamente utile alla salute complessiva del sito.
Ma la relazione corretta è:
traffico abusivo → consumo di risorse o indisponibilità → problema tecnico da risolvere
non:
blocco l’endpoint → Google mi posiziona meglio
Inserire questa modifica in una strategia SEO soltanto per “ottimizzare WordPress” confonde due problemi diversi.
Piuttosto, la gestione del servizio va considerata come uno degli elementi di una strategia più ampia di sicurezza WordPress: aggiornamenti, autenticazione, privilegi degli utenti, firewall, backup e monitoraggio restano molto più importanti della presenza del singolo endpoint.
Conclusione
Questa funzione di WordPress non deve essere né demonizzata né lasciata attiva per inerzia.
Se il tuo sito non la utilizza, bloccare xmlrpc.php è una scelta ragionevole perché elimina un endpoint che non ti porta alcun beneficio e che può ricevere traffico automatizzato.
Se invece Jetpack, un client remoto o un’integrazione ne dipendono, il blocco completo è la soluzione sbagliata. In quel caso conviene proteggere l’accesso, limitare il traffico e, quando possibile, rimuovere soltanto i metodi che non servono.
Ricorda soprattutto la distinzione tecnica più importante della guida: il filtro xmlrpc_enabled non equivale a disabilitare completamente XML-RPC. Se vuoi rendere /xmlrpc.php irraggiungibile, devi intervenire sul server, sul firewall o attraverso una funzione equivalente offerta dal tuo hosting.
La sequenza corretta è quindi:
verifica se il servizio viene usato → identifica le dipendenze → scegli cosa limitare → applica la modifica → testa nuovamente sito e integrazioni.
Se devi intervenire su configurazioni server, firewall o incompatibilità fra plugin e servizi esterni e non vuoi rischiare di bloccare funzionalità legittime, un intervento di assistenza WordPress può permetterti di verificare prima i log e applicare la restrizione nel punto più adatto dell’infrastruttura.