XML-RPC est l'un de ces fichiers que presque personne ne remarque jusqu'au jour où un audit de sécurité le signale comme point faible. Hérité d'une époque où WordPress devait dialoguer avec des logiciels de publication de bureau, ce protocole continue d'exister sur la quasi-totalité des installations, souvent sans que son propriétaire sache à quoi il sert encore.
À quoi servait XML-RPC à l'origine
Le fichier xmlrpc.php, présent à la racine de chaque installation WordPress, permet la communication à distance avec le site via un protocole standardisé. Historiquement, il servait principalement à :
- Publier du contenu depuis des clients de bureau ou des applications mobiles antérieures à l'adoption généralisée de la REST API.
- Gérer les pingbacks et trackbacks, des notifications automatiques échangées entre sites qui se citent mutuellement.
- Faire fonctionner certaines fonctionnalités de Jetpack, dans ses versions plus anciennes.
Pourquoi il est devenu un vecteur d'attaque
Deux usages malveillants expliquent sa mauvaise réputation actuelle :
- L'amplification de force brute : la méthode system.multicall de XML-RPC permet de regrouper plusieurs centaines de tentatives de connexion dans une seule requête HTTP. Un attaquant peut ainsi tester des centaines de combinaisons de mots de passe en une poignée de requêtes, là où une attaque classique sur la page de connexion nécessiterait autant de requêtes séparées, plus facilement détectables par un système comme Fail2ban.
- L'amplification DDoS via pingback : la fonctionnalité pingback peut être manipulée pour forcer un site WordPress à envoyer des requêtes vers une cible tierce choisie par l'attaquant, qui utilise alors des milliers de sites WordPress non protégés comme relais involontaires d'une attaque par déni de service.
Faut-il le désactiver
Pour la grande majorité des sites actuels, oui : les clients de publication de bureau qui en dépendaient ont largement disparu, et la REST API a pris le relais pour les usages modernes, y compris pour les versions récentes de Jetpack. La désactivation se fait simplement via un plugin de sécurité, ou en bloquant directement l'accès au fichier au niveau du serveur (règle .htaccess sous Apache, ou bloc location sous Nginx), sans affecter le reste du site.
La seule situation où il faut vérifier avant de couper : si vous utilisez encore une application tierce ancienne qui publie explicitement via XML-RPC, ou une fonctionnalité spécifique de plugin qui en dépend encore. Un test en environnement de test avant la bascule en production reste la précaution la plus simple.
Vérifier l'usage réel avant de couper
Avant de désactiver XML-RPC définitivement, un rapide coup d'œil dans les journaux d'accès du serveur renseigne sur son usage réel : une recherche des requêtes vers xmlrpc.php dans ces journaux révèle si le fichier reçoit un trafic légitime de votre part (une application de publication que vous utilisez réellement) ou uniquement des tentatives suspectes en provenance d'adresses IP inconnues, souvent en très grand nombre et à intervalles réguliers caractéristiques d'un script automatisé.
Dans l'immense majorité des cas observés sur des sites WordPress classiques, l'essentiel de ce trafic correspond précisément à ce second cas, ce qui confirme que la désactivation n'affectera aucun usage légitime existant.
Pour un blocage plus robuste qu'un simple plugin, la règle peut aussi être appliquée directement au niveau du serveur web : une directive de blocage dans la configuration Nginx (bloc location = /xmlrpc.php { deny all; }) ou une règle équivalente dans le fichier .htaccess sous Apache empêche la requête d'atteindre WordPress, ce qui économise en plus les ressources serveur qu'une tentative bloquée au niveau applicatif continuerait de consommer.
Désactiver XML-RPC casse-t-il Jetpack ?
Les versions actuelles de Jetpack utilisent principalement la REST API plutôt que XML-RPC, mais il reste prudent de vérifier dans la documentation de votre version exacte avant de couper complètement, surtout si certains modules Jetpack spécifiques sont actifs.
Désactiver XML-RPC suffit-il à arrêter toutes les attaques par force brute ?
Non, cela supprime seulement le vecteur d'amplification via system.multicall. La page de connexion classique (wp-login.php) reste exposée et doit être protégée séparément, par exemple via l'authentification à deux facteurs ou une limitation des tentatives de connexion.
Désactiver XML-RPC fait partie des mesures de durcissement simples qui réduisent la surface d'attaque sans affecter l'expérience des visiteurs réels. Le service SiteLock de VSP TECH détecte ce type de tentative d'abus sur votre site, et un certificat SSL valide reste indispensable en complément pour chiffrer l'ensemble des échanges avec votre hébergement WordPress.
