XML-RPC : définition

XML-RPC est à l’origine un protocole générique : un programme envoie une requête XML qui nomme une méthode et ses paramètres, le serveur l’exécute et répond en XML. Dans WordPress, il prend la forme du fichier xmlrpc.php, à la racine du site. Il date d’une époque où l’on écrivait ses articles dans un logiciel de bureau, et il reprend les anciennes API Blogger, metaWeblog et Movable Type en plus des méthodes wp.* propres à WordPress.

À quoi sert XML-RPC aujourd’hui

• Publier à distance depuis une application ou un outil externe qui s’authentifie avec un identifiant et un mot de passe.
• Recevoir des pingbacks, ces notifications envoyées par un autre blog qui vous cite (méthode pingback.ping).
• Faire fonctionner certains services, notamment Jetpack, dont la connexion à WordPress.com passe par xmlrpc.php.

Depuis l’arrivée de l’API REST dans le cœur, la plupart de ces besoins ont une solution plus moderne. Beaucoup de sites n’utilisent plus du tout XML-RPC, alors qu’il reste actif par défaut.

Les risques

La documentation officielle de WordPress cite xmlrpc.php comme une cible fréquente de force brute : chaque appel de publication accepte un identifiant et un mot de passe, sans page à charger ni cookie. En octobre 2015, Sucuri a décrit des attaques qui utilisaient la méthode system.multicall pour tester des centaines de mots de passe dans une seule requête HTTP. WordPress 4.4 a limité cette amplification : après un échec d’authentification, les appels suivants de la même requête échouent aussi. La méthode reste toutefois une source de charge et un motif de blocage fréquent au niveau des pare-feu.

Les pingbacks posent un autre problème. Pour vérifier un pingback, WordPress va lire la page qui prétend le citer, à une adresse fournie par l’expéditeur. Des milliers de sites peuvent ainsi être utilisés comme relais d’une attaque DDoS contre une même victime, sans avoir été piratés.

Pour WordPress : fermer ou limiter XML-RPC

Point souvent mal compris : le filtre xmlrpc_enabled ne désactive pas XML-RPC. Sa documentation précise qu’il ne coupe que les méthodes qui exigent une authentification, et pas les pingbacks. Selon votre usage :

• Aucun usage : bloquez xmlrpc.php au niveau du serveur ou du CDN (bloc <Files "xmlrpc.php"> sous Apache, location = /xmlrpc.php { deny all; } sous Nginx). C’est la seule méthode qui évite aussi la charge de PHP.
• Jetpack : même blocage, avec une exception pour les adresses IP publiées par Jetpack.
• Publication à distance : gardez le fichier, retirez pingback.ping via le filtre xmlrpc_methods, et utilisez des mots de passe d’application, révocables un par un.

Après le changement, ouvrez /xmlrpc.php dans une fenêtre privée : la réponse doit être 403 ou 404. Notre article XML-RPC sur WordPress : risques, usages et désactivation compare les méthodes en détail. Si vous gardez XML-RPC, une double authentification sur les comptes qui publient limite l’intérêt des mots de passe volés.

Le module Durcissement de WP Masquerade traite XML-RPC dans sa version gratuite : un premier niveau retire les méthodes de pingback, le suivant fait répondre xmlrpc.php par une erreur 404, en prévenant que Jetpack et certaines applications cesseront de fonctionner. Comme le blocage est fait par WordPress, PHP reste sollicité : une règle serveur ou CDN supprime aussi cette charge. Les requêtes vers l’adresse fermée sont comptées comme un piège à robots.