À la racine de chaque installation WordPress, on trouve un fichier nommé xmlrpc.php. Peu connu du grand public, il est pourtant là depuis les toutes premières versions du CMS. Si vous vous intéressez à la sécurité ou à l’optimisation de votre site, vous avez probablement déjà entendu parler de ce fichier – souvent désactivé, voire supprimé. Mais pourquoi existe-t-il ? À quoi sert-il encore aujourd’hui ? Et faut-il le désactiver ? Dans cet article, nous allons explorer le rôle historique et technique du fichier xmlrpc.php, ses usages encore pertinents, les risques associés, ainsi que les bonnes pratiques pour gérer sa présence dans une installation WordPress moderne.

Les origines et fonction du fichier xmlrpc.php

Le fichier xmlrpc.php est un script d’interface distant basé sur le protocole XML-RPC (Remote Procedure Call via XML), un protocole créé à la fin des années 1990 permettant à des applications distantes de communiquer entre elles via des requêtes HTTP et des structures XML. Ce protocole était une des premières tentatives de créer des interfaces API simples entre systèmes hétérogènes. WordPress a adopté XML-RPC très tôt, dès la version 1.5 (2005), pour permettre une interaction distante avec un site WordPress. Le fichier xmlrpc.php agit comme un point d’entrée pour ces requêtes : clients mobiles, éditeurs externes, outils de publication, pingbacks ou trackbacks y font appel pour interagir avec le site sans passer par l’interface web d’administration.

Voici quelques exemples d’usages historiques de xmlrpc.php :

• Publier un article à distance depuis Windows Live Writer ou Open Live Writer ;
• Utiliser des applications mobiles (l’application WordPress iOS ou Android) pour publier, modérer ou éditer du contenu ;
• Permettre le pingback entre sites, une fonction native de WordPress pour notifier des liens entrants ;
• Gérer des commentaires ou utilisateurs depuis des outils externes ;
• Recevoir des signaux depuis des plateformes comme Jetpack, notamment pour le système de statistiques ou de sécurité distante.

À l’époque où l’API REST n’existait pas encore, le fichier xmlrpc.php était donc la seule manière officielle d’interagir avec un site WordPress à distance.

Analyse technique du fichier xmlrpc.php dans le cœur de WordPress

Le fichier xmlrpc.php constitue donc le point d’entrée officiel pour les communications XML-RPC dans WordPress. Il est exécuté lorsqu’une requête distante est envoyée vers /xmlrpc.php, permettant à des outils tiers (applications mobiles, services d’édition, connecteurs) d’interagir avec le site. Ce script est relativement court, mais il orchestre l’appel à plusieurs composants fondamentaux du CMS. Voici son analyse technique ligne par ligne.

1. La définition du contexte XML-RPC

define( 'XMLRPC_REQUEST', true );

Cette constante signale à WordPress que la requête en cours est une requête XML-RPC. Elle peut être utilisée par des plugins ou par le cœur du CMS pour adapter certains comportements ou désactiver des fonctionnalités non pertinentes dans ce contexte.

2. Le nettoyage des cookies parasites

$_COOKIE = array();

Les cookies sont vidés en début d’exécution. Cela permet de garantir qu’aucune donnée de session ou de navigation parasite ne vient interférer avec l’analyse de la requête XML-RPC, notamment dans le cas d’applications mobiles ou de clients embarqués dans des navigateurs.

3. La lecture manuelle des données brutes

$HTTP_RAW_POST_DATA = file_get_contents( 'php://input' );

Cette partie gère la récupération du corps brut de la requête XML (le payload XML). La variable $HTTP_RAW_POST_DATA est obsolète en PHP 7+, mais utilisée ici pour rétrocompatibilité. La fonction file_get_contents('php://input') permet de récupérer les données XML envoyées avec la requête POST.

4. La correction de format pour une compatibilité avec d’anciens clients

$HTTP_RAW_POST_DATA = trim( $HTTP_RAW_POST_DATA );

On retire les espaces inutiles en début de contenu, car certains anciens éditeurs distants n’envoyaient pas directement la déclaration XML <?xml en première ligne, ce qui pouvait poser des problèmes d’analyse.

5. La gestion du paramètre RSD (Really Simple Discovery)

if ( isset( $_GET['rsd'] ) ) { ... }

Si l’URL contient le paramètre ?rsd, le script génère un document XML spécial qui décrit les API disponibles (WordPress, MetaWeblog, MovableType, etc.). C’est une sorte de « carte de visite » du site WordPress à destination des éditeurs distants compatibles. Ce document RSD est utile pour les applications qui détectent automatiquement les points d’entrée disponibles.

6. Le chargement de l’environnement WordPress

require_once __DIR__ . '/wp-load.php';

Cette ligne initialise WordPress en important tous les fichiers nécessaires. C’est ce qui permet au fichier xmlrpc.php d’avoir accès à l’ensemble des fonctions, objets et APIs WordPress, comme s’il s’agissait d’une page normale du site.

7. Le chargement des classes nécessaires au traitement XML-RPC

require_once ABSPATH . 'wp-admin/includes/admin.php';
require_once ABSPATH . WPINC . '/class-IXR.php';
require_once ABSPATH . WPINC . '/class-wp-xmlrpc-server.php';

Ces fichiers incluent les classes qui définissent le serveur XML-RPC (wp_xmlrpc_server) ainsi que l’implémentation du protocole IXR (une version améliorée de XML-RPC pour PHP). Ce sont ces classes qui interprètent les méthodes XML-RPC appelées par le client.

8. L’initialisation et l’exécution du serveur XML-RPC

$wp_xmlrpc_server_class = apply_filters( 'wp_xmlrpc_server_class', 'wp_xmlrpc_server' );
$wp_xmlrpc_server = new $wp_xmlrpc_server_class();
$wp_xmlrpc_server->serve_request();

WordPress permet ici aux développeurs de modifier la classe utilisée pour gérer les requêtes XML-RPC grâce à un filtre (wp_xmlrpc_server_class). Par défaut, il utilise wp_xmlrpc_server. Ensuite, la méthode serve_request() est appelée, ce qui déclenche le traitement complet de la requête XML.

9. La fonction de log obsolète

function logIO( $io, $msg ) {
    _deprecated_function( __FUNCTION__, '3.4.0', 'error_log()' );
    if ( ! empty( $GLOBALS['xmlrpc_logging'] ) ) {
        error_log( $io . ' - ' . $msg );
    }
}

Enfin, le script inclut une fonction logIO() autrefois utilisée pour enregistrer des logs liés aux requêtes XML-RPC. Cette fonction est maintenant dépréciée depuis WordPress 3.4, car remplacée par error_log(). Elle n’est conservée que pour compatibilité avec d’anciens plugins ou scripts personnalisés. Le fichier xmlrpc.php n’est pas complexe en soi : il se contente de préparer l’environnement, d’interpréter la requête XML et de déclencher le serveur XML-RPC interne à WordPress. Toutefois, il ouvre une porte directe vers le cœur du CMS. S’il n’est pas utilisé activement par des services ou outils légitimes, il est préférable de le désactiver proprement, comme nous l’avons vu dans les sections précédentes, afin de limiter les risques d’exploitation ou d’abus.

xmlrpc.php sur WP aujourd’hui : Risques, abus et alternatives modernes

Avec l’introduction de l’API REST à partir de WordPress 4.4 (2015), l’utilité de xmlrpc.php a commencé à diminuer. Aujourd’hui, la plupart des applications modernes se connectent via l’API REST, plus sécurisée, plus performante et mieux adaptée aux besoins des développeurs. Pourtant, le fichier xmlrpc.php est toujours présent par défaut dans toutes les installations WordPress, même si ses usages sont de moins en moins nombreux.

Les raisons pour lesquelles xmlrpc.php est problématique aujourd’hui

Le fichier xmlrpc.php, bien qu’historiquement utile, est aujourd’hui considéré comme un point d’entrée sensible dans la surface d’exposition de WordPress. Il est régulièrement ciblé par des scripts d’automatisation, des scanners de vulnérabilités et des bots malveillants. Son architecture basée sur le protocole XML-RPC, peu verbeux et difficile à journaliser finement sans outil spécialisé, le rend également moins observable dans les logs standards d’un serveur Apache ou Nginx.

Voici les principaux vecteurs d’exploitation associés à ce fichier :

• Brute force via system.multicall : contrairement à wp-login.php qui nécessite une requête HTTP distincte pour chaque tentative de connexion, xmlrpc.php permet d’encapsuler des dizaines voire des centaines de tentatives dans une seule requête grâce à la méthode system.multicall. Cela rend les attaques de type brute force distribuée plus difficiles à détecter et à bloquer par des outils classiques de WAF ou de rate limiting, qui comptabilisent les requêtes plutôt que le volume d’instructions XML encapsulées. Des bots peuvent ainsi tester massivement des combinaisons login/mot de passe sans déclencher immédiatement d’alerte côté serveur ;
• Abus de pingbacks comme relai DDoS : la fonction pingback.ping exposée dans xmlrpc.php peut être détournée pour transformer un site WordPress en agent de relais dans une attaque DDoS. L’attaquant envoie une requête XML-RPC vers plusieurs sites WordPress vulnérables en leur demandant de faire un pingback vers une cible. Résultat : des dizaines de sites envoient simultanément une requête vers la même adresse, ce qui surcharge la bande passante ou les ressources serveur de la cible. Ce phénomène est connu sous le nom de pingback amplification, car l’attaquant multiplie sa capacité d’envoi en exploitant des tiers ;
• Exécution indirecte de payloads XML malformés : certaines vulnérabilités documentées dans des extensions ou dans le cœur de WordPress ont exploité le fait que xmlrpc.php accepte des contenus XML relativement permissifs. Dans le passé, des failles comme CVE-2015-5622 ou CVE-2017-5487 ont montré que des requêtes XML-RPC pouvaient être utilisées pour contourner des contrôles d’authentification, injecter du code ou interagir avec la base de données via des chemins inattendus. Bien que ces failles soient corrigées dans les versions récentes, la maintenance des thèmes/plugins obsolètes expose encore ce vecteur.

À cela s’ajoute une autre difficulté : le monitoring du trafic XML-RPC est souvent négligé. La plupart des solutions d’analyse de journaux HTTP (Apache, Nginx, Cloudflare) ne décryptent pas le contenu XML, ce qui rend les intentions malveillantes peu visibles sans inspection poussée. Résultat : des attaques peuvent passer sous les radars si l’on ne met pas en place un reverse proxy ou un filtrage WAF adapté.

Pour toutes ces raisons, de nombreux administrateurs système, hébergeurs spécialisés et agences WordPress choisissent de désactiver complètement l’accès à xmlrpc.php, soit en bloquant son exécution au niveau du serveur web, soit en filtrant les requêtes via une extension de sécurité (Wordfence, iThemes Security, Sucuri, etc.). Dans certains cas, le fichier est même désactivé via le hook xmlrpc_enabled dans le thème ou un plugin personnalisé, empêchant toute réponse aux requêtes même s’il reste accessible physiquement sur le serveur.

Comment désactiver xmlrpc.php proprement

Si votre site WordPress n’utilise aucun service ou application nécessitant XML-RPC (comme Jetpack, l’application mobile officielle ou un éditeur distant), il est fortement recommandé de désactiver xmlrpc.php pour limiter votre surface d’attaque. Plusieurs méthodes permettent de bloquer proprement son accès, que vous soyez sur un serveur Apache, Nginx ou que vous préfériez utiliser un plugin WordPress.

Désactiver xmlrpc.php côté serveur avec Apache (.htaccess)

Pour les hébergements fonctionnant sous Apache (serveurs mutualisés ou VPS), la méthode la plus simple consiste à bloquer directement l’accès à ce fichier via le fichier htaccess situé à la racine de votre site WordPress. Voici la directive à insérer :

<Files xmlrpc.php>
  Order allow,deny
  Deny from all
</Files>

Cette configuration interdit tout accès HTTP au fichier xmlrpc.php, ce qui rend impossible son exploitation externe tout en évitant de le supprimer physiquement. Elle agit dès la couche serveur, avant que WordPress n’ait l’occasion d’interpréter la requête, ce qui est à la fois plus rapide et plus sûr.

Blocage via Nginx : Configuration serveur directe

Si votre site est hébergé sur un serveur Nginx, vous pouvez insérer une directive spécifique dans le bloc de configuration de votre site (généralement situé dans /etc/nginx/sites-available/). Voici l’exemple à utiliser :

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

Cette règle bloque l’accès au fichier xmlrpc.php et empêche la génération de logs parasites pour les requêtes interdites. Elle est idéale pour alléger les journaux en cas de scans automatisés et attaques de type brute force XML-RPC. N’oubliez pas de recharger la configuration Nginx après modification :

sudo nginx -t && sudo systemctl reload nginx

Désactivation de xmlrpc avec un plugin WordPress

Si vous n’avez pas accès au serveur ou ne souhaitez pas modifier les fichiers système, plusieurs plugins de sécurité WordPress permettent de désactiver XML-RPC via l’interface d’administration :

• Wordfence : dans les réglages avancés du pare-feu, vous pouvez bloquer les accès suspects à xmlrpc.php et détecter les requêtes system.multicall.
• iThemes Security : une option explicite permet de désactiver XML-RPC ou uniquement certaines méthodes vulnérables comme pingback.ping.
• Disable XML-RPC (plugin léger dédié) : supprime toutes les fonctionnalités XML-RPC de WordPress via un simple toggle.

Ces solutions sont adaptées aux utilisateurs non techniques, ou aux environnements mutualisés où la configuration serveur est limitée.

Désactiver via le code du thème ou un plugin custom

Pour les développeurs, il est également possible de désactiver proprement XML-RPC à l’aide d’un filtre WordPress dans le fichier functions.php de votre thème ou dans un plugin maison :

add_filter( 'xmlrpc_enabled', '__return_false' );

Cette méthode préserve le fichier physique mais rend toutes les fonctions XML-RPC inactives. WordPress retournera automatiquement une erreur aux appels XML-RPC entrants, tout en maintenant la compatibilité structurelle du CMS.

Vérifiez la compatibilité avec vos services connectés

Avant de bloquer ou désactiver xmlrpc.php, il est important de tester les dépendances potentielles de votre site :

• Si vous utilisez l’application mobile WordPress pour publier ou modérer, XML-RPC est requis ;
• Certains services comme Jetpack, VaultPress ou ManageWP utilisent encore XML-RPC pour la synchronisation distante ;
• Des connecteurs CRM, ERP ou de gestion de contenus tiers peuvent également envoyer des requêtes via ce protocole.

En cas de doute, vous pouvez monitorer les requêtes entrantes sur xmlrpc.php via les journaux du serveur (access.log) ou via un plugin de log HTTP pour WordPress. Si aucune activité légitime n’est détectée, vous pouvez désactiver l’accès en toute sécurité.

Enfin, dans une optique DevSecOps ou CI/CD, pensez à intégrer le blocage de XML-RPC dans vos playbooks Ansible, vos scripts d’installation automatisée ou vos configurations Docker, pour assurer une désactivation systématique sur tous vos environnements.

Faut-il supprimer le fichier xmlrpc dans WordPress ?

Non, il ne faut jamais supprimer manuellement le fichier xmlrpc.php d’une installation WordPress, même si vous ne l’utilisez pas. Ce fichier fait partie intégrante du cœur du CMS depuis ses premières versions. Bien qu’il soit de moins en moins utilisé dans les architectures modernes (remplacé en grande partie par l’API REST), il reste un composant maintenu et référencé dans le code source principal.

Supprimer ce fichier peut entraîner plusieurs effets indésirables :

• Problèmes de mise à jour : lors des prochaines mises à jour automatiques ou manuelles de WordPress, le gestionnaire de fichiers peut détecter une incohérence dans l’arborescence. Dans certains cas, cela peut provoquer des échecs de mise à jour ou la réintégration automatique du fichier, voire des conflits de permission si les fichiers système sont patchés ;
• Déclenchement d’erreurs fatales : certains thèmes ou plugins anciens ou mal codés peuvent faire appel à xmlrpc.php ou à ses méthodes. Sa suppression pourrait entraîner des erreurs 500 ou des appels à des fonctions inexistantes, notamment si des requêtes REST échouent et retombent sur XML-RPC comme fallback ;
• Incompatibilité avec certains services : certains outils de sauvegarde, de monitoring, ou encore des applications mobiles (comme l’application WordPress officielle) nécessitent encore xmlrpc.php pour fonctionner. Sa suppression brutale peut bloquer des intégrations distantes, parfois sans message d’erreur clair.

La bonne pratique recommandée par la communauté technique est de désactiver proprement l’accès à ce fichier, sans le supprimer. Cela permet de préserver l’intégrité du cœur WordPress, tout en neutralisant les vecteurs d’attaque associés. Par ailleurs, supprimer un fichier du cœur WordPress sans comprendre ses implications contrevient aux bonnes pratiques de maintenance du CMS. WordPress fonctionne comme une structure modulaire, mais attend que l’ensemble de ses composants de base soient présents et accessibles. Tout fichier supprimé manuellement est susceptible de compromettre la stabilité ou la maintenabilité de l’application.

Dans un cadre professionnel ou en environnement de production, il est donc impératif de gérer la désactivation de xmlrpc.php via des méthodes non destructives comme vu plus haut, réversibles, et traçables (comme une règle versionnée dans Git ou un script d’automatisation d’infrastructure). Cela garantit la sécurité du site sans nuire à sa compatibilité ou à sa capacité d’évolution.