XML-RPC WordPress: come e perché disabilitarlo nel 2026

Cos’è XML-RPC e perché esiste ancora in WordPress

XML-RPC è un protocollo di comunicazione remota introdotto in WordPress 3.5 nel 2012 per permettere la pubblicazione di contenuti da applicazioni esterne. Nato per abilitare funzionalità come la pubblicazione da client desktop (Windows Live Writer, MarsEdit) e l’integrazione con servizi esterni, XML-RPC è rimasto attivo di default in WordPress per garantire retrocompatibilità.

Nel 2026, XML-RPC è tecnicamente obsoleto: la REST API, introdotta in WordPress 4.7 (2016), offre funzionalità superiori con migliore sicurezza e performance. Tuttavia, il file xmlrpc.php resta attivo per default nell’installazione standard di WordPress, principalmente per supportare:

• Jetpack (che usa XML-RPC per alcune funzionalità di sincronizzazione)
• Applicazioni mobile legacy ancora in uso
• Plugin datati che non sono stati aggiornati alla REST API
• Pingback e trackback tra siti WordPress

Il problema è che mantenere XML-RPC attivo senza necessità espone i siti a rischi di sicurezza documentati e sfruttati attivamente in produzione.

I rischi concreti di XML-RPC attivo

Secondo i dati di Wordfence, nel 2025 oltre il 37% degli attacchi brute force su WordPress hanno sfruttato XML-RPC come vettore principale. I numeri parlano chiaro: non si tratta di vulnerabilità teoriche, ma di exploit attivi utilizzati quotidianamente.

Attacchi brute force amplificati

Il metodo system.multicall di XML-RPC permette di inviare centinaia di tentativi di login in una singola richiesta HTTP. Questo bypassa la maggior parte dei sistemi di rate limiting che contano le richieste HTTP anziché i tentativi di autenticazione effettivi.

Un attaccante può testare 500 combinazioni username/password con una sola chiamata POST a xmlrpc.php, rendendo inefficaci molte protezioni standard. Nel monitoraggio dei nostri clienti AgencyPilot, abbiamo rilevato picchi di oltre 2.000 tentativi al minuto su siti con XML-RPC esposto.

DDoS via pingback

Il metodo pingback.ping può essere sfruttato per attacchi DDoS di tipo reflection. Gli attaccanti usano siti WordPress come amplificatori, inviando richieste di pingback verso target esterni. Il sito WordPress diventa inconsapevolmente parte di una botnet.

Questa tecnica è stata documentata estensivamente dal 2014, ma resta efficace nel 2026 proprio perché molti siti mantengono XML-RPC attivo senza necessità.

Information disclosure

Chiamate a system.listMethods rivelano i metodi XML-RPC disponibili, facilitando la ricognizione preliminare. Anche senza credenziali valide, un attaccante può mappare le funzionalità esposte e identificare potenziali vulnerabilità.

Consumo risorse server

Le richieste XML-RPC sono computazionalmente più costose delle normali chiamate HTTP. Attacchi sostenuti possono saturare CPU e memoria, degradando le performance o causando downtime anche su infrastrutture robuste.

Come verificare se XML-RPC è attivo

Prima di disabilitare XML-RPC, è fondamentale verificare se è effettivamente utilizzato dai tuoi siti. Ecco i metodi di verifica più affidabili:

Test manuale via cURL

Il test più diretto utilizza cURL per inviare una richiesta POST al file xmlrpc.php:

curl -X POST -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' https://tuosito.it/xmlrpc.php

Se XML-RPC è attivo, riceverai una risposta XML con l’elenco dei metodi disponibili. Se è disabilitato o bloccato, otterrai un errore HTTP (403, 404, 405) o nessuna risposta XML valida.

Verifica nei log di accesso

Analizza i log Apache/Nginx per identificare richieste legittime a xmlrpc.php negli ultimi 30-60 giorni:

grep "xmlrpc.php" /var/log/nginx/access.log | grep -v "bot" | wc -l

Se il conteggio è zero o contiene solo tentativi di attacco (identificabili da user-agent sospetti o volumi anomali), il sito non usa XML-RPC in modo legittimo.

Dipendenze plugin e servizi

Verifica se utilizzi servizi che richiedono XML-RPC:

• Jetpack: le funzionalità core richiedono XML-RPC attivo
• App mobile WordPress: può funzionare via REST API dalla versione 13.0+
• Plugin di pubblicazione remota: verifica documentazione per supporto REST API
• Servizi IFTTT legacy: molti sono migrati alla REST API

Metodi per disabilitare XML-RPC

Esistono diversi approcci per disabilitare XML-RPC, con livelli di protezione e complessità differenti. La scelta dipende dall’infrastruttura e dai requisiti specifici.

Metodo 1: Plugin dedicato (soluzione rapida)

Il plugin “Disable XML-RPC” (oltre 300.000 installazioni attive nel 2026) offre disabilitazione completa con un click. Vantaggi: semplicità, nessuna modifica al codice. Svantaggi: aggiunge un plugin alla stack, possibile overhead minimo.

Per installazioni multiple, AgencyPilot permette l’attivazione massiva su tutti i siti client in un’unica operazione.

Metodo 2: Filtro WordPress nel tema o plugin custom

Aggiungere questo codice a functions.php del tema child o in un plugin mu-plugin:

add_filter('xmlrpc_enabled', '__return_false');

Questo metodo disabilita XML-RPC a livello applicativo. È pulito ed efficiente, ma non blocca completamente le richieste: WordPress elabora comunque la chiamata prima di rifiutarla.

Metodo 3: Blocco a livello server (più sicuro)

Per Nginx, aggiungere nel blocco server:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Per Apache, aggiungere in .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Questo approccio blocca le richieste prima che raggiungano PHP, riducendo completamente il carico computazionale. È la soluzione più performante e sicura.

Metodo 4: Blocco selettivo dei metodi pericolosi

Se devi mantenere XML-RPC attivo per specifici servizi ma vuoi mitigare i rischi, puoi disabilitare solo i metodi pericolosi:

add_filter('xmlrpc_methods', function($methods) {
    unset($methods['system.multicall']);
    unset($methods['pingback.ping']);
    return $methods;
});

Questa soluzione di compromesso mantiene la compatibilità con servizi come Jetpack, bloccando i vettori di attacco più sfruttati.

Gestione di Jetpack e servizi WordPress.com

Jetpack è il caso d’uso più comune che richiede XML-RPC attivo. Tuttavia, dal 2024 Jetpack ha progressivamente migrato funzionalità alla REST API. Nel 2026, la situazione è:

• Jetpack 13.0+: la maggior parte delle funzionalità (statistiche, protezione brute force, CDN) funziona via REST API
• Pubblicazione automatica social: ancora basata su XML-RPC
• Notifiche push: migrata a REST API
• Backup in tempo reale: utilizza connessione diretta, non XML-RPC

Se usi Jetpack, verifica nella documentazione ufficiale quali moduli specifici hai attivato. Molte agenzie stanno migrando a soluzioni alternative per eliminare la dipendenza da XML-RPC.

Monitoraggio e verifica post-disabilitazione

Dopo aver disabilitato XML-RPC, è fondamentale monitorare per 2-4 settimane:

1. Funzionalità client: verifica che app mobili, plugin di pubblicazione e integrazioni continuino a funzionare
2. Log degli errori: controlla che non compaiano errori relativi a servizi che tentano di usare XML-RPC
3. Tentativi di attacco bloccati: monitora i log per confermare che gli attacchi vengano effettivamente respinti
4. Performance: misura il miglioramento nei tempi di risposta e nel carico server

In AgencyPilot, il nostro sistema di monitoraggio automatico rileva tentativi di accesso a xmlrpc.php e genera alert se vengono rilevati pattern sospetti, anche dopo la disabilitazione.

Best practice per la sicurezza XML-RPC nel 2026

Indipendentemente dal metodo scelto, segui queste linee guida:

• Audit regolare: verifica trimestralmente se XML-RPC è ancora necessario
• Documentazione dipendenze: mantieni un elenco aggiornato dei servizi che richiedono XML-RPC
• Whitelist IP se necessario: se devi mantenere XML-RPC attivo, limita l’accesso solo agli IP fidati
• Autenticazione forte: se XML-RPC resta attivo, usa password robuste e 2FA obbligatoria
• WAF rules: configura regole firewall specifiche per monitorare pattern di attacco XML-RPC
• Rate limiting applicativo: se usi Cloudflare, Sucuri o WAF similari, configura limiti stringenti per xmlrpc.php

Per agenzie che gestiscono decine o centinaia di siti client, standardizzare la disabilitazione di XML-RPC dovrebbe essere parte della procedura di hardening iniziale, insieme a configurazione firewall, aggiornamenti automatici e backup programmati.

FAQ

Disabilitare XML-RPC rompe l’app mobile di WordPress?

No, le versioni moderne dell’app WordPress (dalla 13.0 in poi, rilasciata nel 2023) utilizzano primariamente la REST API per tutte le operazioni. L’app continuerà a funzionare normalmente anche con XML-RPC disabilitato. Solo versioni molto datate dell’app potrebbero avere problemi, ma sono ormai fuori supporto.

Jetpack smette di funzionare se disabilito XML-RPC?

Dipende dalle funzionalità Jetpack che utilizzi. Dal 2024, la maggior parte dei moduli Jetpack è stata migrata alla REST API. Tuttavia, alcune funzionalità legacy come la pubblicazione automatica su social potrebbero ancora richiedere XML-RPC. Verifica nella dashboard Jetpack quali moduli hai attivi e consulta la documentazione ufficiale per confermare la compatibilità.

Il blocco via .htaccess è meglio del filtro WordPress?

Sì, il blocco a livello server (Nginx o Apache) è superiore per sicurezza e performance. Blocca le richieste prima che raggiungano PHP, eliminando completamente il carico computazionale e impedendo qualsiasi processing da parte di WordPress. Il filtro xmlrpc_enabled è più semplice da implementare ma le richieste vengono comunque processate parzialmente.

Come verifico se i miei clienti subiscono attacchi XML-RPC?

Analizza i log di accesso cercando richieste POST a xmlrpc.php con volumi anomali. Un sito normale riceve zero o poche richieste legittime. Se vedi centinaia o migliaia di POST da IP multipli, sono attacchi in corso. Tool come Wordfence o Sucuri Security mostrano questi tentativi nella dashboard. AgencyPilot aggrega queste metriche per tutti i siti client in un’unica vista, facilitando l’identificazione di siti sotto attacco.

Posso disabilitare solo alcuni metodi XML-RPC invece di tutto?

Sì, usando il filtro xmlrpc_methods puoi rimuovere selettivamente i metodi più pericolosi come system.multicall e pingback.ping mantenendo attivi quelli necessari per servizi specifici. Questo è un compromesso ragionevole se hai dipendenze da XML-RPC che non puoi eliminare immediatamente, ma pianifica comunque una migrazione completa.