XML-RPC
XML-RPC est l'interface d'appel à distance de WordPress, servie par le fichier xmlrpc.php, qui laisse un logiciel extérieur publier ou modifier le contenu d'un site sans passer par le tableau de bord.
Définition
XML-RPC est l’interface d’appel à distance de WordPress, servie par le fichier xmlrpc.php, qui laisse un logiciel extérieur publier ou modifier le contenu d’un site sans passer par le tableau de bord. Cette interface est présente sur toute installation WordPress standard, active par défaut, et elle accepte un identifiant et un mot de passe à chaque appel.
À quoi sert le fichier xmlrpc.php ?
Il permet de piloter un site WordPress depuis un autre logiciel.
La documentation officielle décrit XML-RPC comme une interface qui a pris la suite des anciennes API Blogger, MovableType et metaWeblog. Concrètement, elle expose la gestion des articles, des catégories, des médias, des commentaires, des réglages et des comptes. Un logiciel de publication installé sur un ordinateur, une application mobile ou un service tiers peut ainsi écrire dans le site sans jamais ouvrir le tableau de bord.
Cette interface a été conçue à une époque où l’on publiait depuis un client de bureau. Les usages modernes passent aujourd’hui par l’API REST de WordPress, arrivée avec la version 4.7, mieux documentée et mieux contrôlée. Le protocole XML-RPC reste pourtant en place sur la majorité des installations, parce que rien ne l’en retire et que quelques services, dont certaines applications mobiles, continuent de s’en servir. Quand ce point d’entrée a servi à publier des pages indésirables, il faut aussi faire retirer les contenus déposés.
Pourquoi les robots l’attaquent en priorité
Parce qu’elle accepte des identifiants sans afficher de formulaire.
La page consacrée aux attaques par force brute dans la documentation WordPress est explicite : xmlrpc.php est une cible fréquente, la méthode system.multicall en particulier, et il est conseillé de désactiver l’interface si elle ne sert pas. Cette méthode groupait plusieurs appels dans une seule requête, ce qui permettait d’essayer un grand nombre de mots de passe en une fois, là où la page de connexion en accepte un par envoi.
Le second intérêt du fichier pour un attaquant est plus discret : il n’est pas visible. Personne ne surveille une adresse que personne ne visite. Un site peut avoir sa page de connexion masquée, un compte administrateur bien nommé et un mot de passe long, et laisser cette porte ouverte sans jamais s’en apercevoir.
Désactiver le fichier n’est pas anodin. Certaines applications mobiles, des services de sauvegarde ou de statistiques et quelques extensions de connexion continuent d’appeler cette interface. La coupure se teste sur un site de préproduction, ou se fait en surveillant les services connectés pendant quelques jours. Une fonction cassée sans lien apparent avec la sécurité est souvent une coupure de XML-RPC oubliée.
Comment fermer l’interface proprement
Trois niveaux, du plus réversible au plus solide.
Inventorier ce qui s’en sert
Application mobile, service de sauvegarde, outil de publication, extension de connexion. Cet inventaire se fait avant, jamais après la coupure.
Filtrer par extension ou par code
WordPress expose un filtre qui désactive l’interface. C’est réversible en une désactivation, ce qui est aussi sa limite : le jour où l’extension saute, la porte se rouvre sans alerte.
Refuser en amont du site
Une règle de serveur, écrite dans le fichier .htaccess ou dans le pare-feu de l’hébergement, rejette la requête avant que PHP ne démarre. C’est la seule méthode qui ne coûte rien en ressources.
Contrôler le résultat
Le fichier doit répondre par un refus ou une page introuvable, en direct, et non seulement dans les réglages d’une extension.
Ce que cela donne sur un site réel
Mesure du 5 septembre 2026, sur un mois de journaux d’un site vitrine WordPress d’une trentaine de pages. Du 31 juillet au 31 août, 205 requêtes ont visé ce fichier, venues de 86 machines différentes, sur 28 jours du mois. Aucune n’a obtenu ce qu’elle cherchait : 143 envois de données ont reçu une redirection, qui perd le contenu de la requête au passage, et 59 lectures une page introuvable. Une seule réponse en 200 apparaît dans tout le mois, le 7 août, pour un corps de 403 octets. Deux détails valent le déplacement. Les robots ne se contentent pas de l’adresse habituelle : ils essaient aussi les chemins d’installations rangées dans un sous-dossier, wp, wordpress, web, wpsite. Et le refus coûte cher, parce qu’il est rendu par le site lui-même : les 61 pages introuvables servies pèsent 4,2 mégaoctets, soit 68 kilooctets par tentative. Une règle de serveur aurait répondu en quelques octets.
Questions fréquentes
Faut-il désactiver XML-RPC sur tous les sites ?
Sur la plupart, oui, parce que plus rien ne s’en sert. La règle est de vérifier d’abord ce qui l’appelle : une application mobile ou un service de sauvegarde connecté suffit à rendre la coupure visible pour l’utilisateur.
Comment savoir si mon site l’a encore ouverte ?
En appelant votresite.fr/xmlrpc.php depuis un navigateur. Une interface active affiche un message indiquant qu’elle n’accepte que des envois de données. Un refus ou une page introuvable signale qu’elle est fermée.
Bloquer ce fichier suffit-il à arrêter la force brute ?
Non. Il reste la page de connexion, et le compte se protège d’abord par un mot de passe long et unique et par la double authentification. Fermer cette porte retire une voie d’essai, pas le risque.
Les pings entre sites vont-ils cesser de fonctionner ?
Oui, les rétroliens, ou pingbacks, passent par cette interface de WordPress. C’est souvent un bénéfice : ils servent principalement à envoyer du spam de commentaire, et leur perte se remarque rarement.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.