Comment activer et désactiver xmlrpc.php dans WordPress (et pourquoi c’est important)

Le fichier xmlrpc.php est un composant central de WordPress qui expose un point de terminaison API XML-RPC, permettant aux applications distantes de s’authentifier et d’exécuter des opérations côté serveur — publier des articles, gérer des commentaires, déclencher des pingbacks, et bien plus encore. Étant donné qu’il accepte par défaut des requêtes POST non authentifiées et les traite avant que la plupart des couches de sécurité ne s’activent, il constitue l’une des surfaces d’attaque les plus fréquemment exploitées dans toute installation WordPress.

Si vous n’utilisez pas l’application mobile WordPress, Jetpack, ou tout service tiers nécessitant explicitement XML-RPC, désactiver xmlrpc.php est la posture de sécurité par défaut correcte. Si vous dépendez de ces intégrations, vous pouvez renforcer le point de terminaison plutôt que de le supprimer entièrement.

Qu’est-ce que xmlrpc.php et comment fonctionne-t-il

XML-RPC (Extensible Markup Language Remote Procedure Call) est un protocole qui encode les appels de fonctions en XML et les transmet via HTTP. WordPress intègre un serveur XML-RPC complet depuis la version 3.5, implémenté dans le fichier xmlrpc.php situé dans le répertoire racine de WordPress.

Lorsqu’un client distant — une application mobile, un client de blogging de bureau, ou un script d’automatisation — envoie une requête POST à https://yourdomain.com/xmlrpc.php, WordPress analyse la charge utile XML, authentifie les identifiants intégrés dans le corps de la requête, et exécute la méthode demandée. L’ensemble de l’échange se déroule en un seul aller-retour HTTP, ce qui constitue à la fois sa force et sa faiblesse fondamentale du point de vue de la sécurité.

Méthodes XML-RPC principales exposées par WordPress

• wp.newPost / wp.editPost — créer et mettre à jour des articles à distance
• wp.getComments / wp.deleteComment — gérer les commentaires
• wp.uploadFile — téléverser des médias sur le serveur
• pingback.ping — notifier un site distant qu’il a été lié
• system.multicall — regrouper plusieurs appels de méthodes en une seule requête HTTP

La méthode system.multicall est particulièrement dangereuse. Une seule requête HTTP peut regrouper des centaines d’appels wp.getUsersBlogs, chacun testant un mot de passe différent. Cela permet à un attaquant d’effectuer des milliers de tentatives d’authentification en ne générant qu’une seule entrée dans le journal du serveur, contournant ainsi les outils de limitation de débit qui comptent les requêtes individuelles.

Risques de sécurité liés au maintien de xmlrpc.php activé

Amplification de la force brute via system.multicall

Les attaques par force brute traditionnelles envoient une paire d’identifiants par requête HTTP. Avec XML-RPC, un attaquant encapsule 500 tentatives de connexion dans une seule charge utile system.multicall. Une règle fail2ban standard ou un compteur de tentatives de connexion voit une seule requête ; l’attaquant obtient 500 essais. Ce n’est pas un risque théorique — c’est l’exploit XML-RPC le plus couramment observé dans la pratique.

DDoS amplifié via les pingbacks

WordPress traite automatiquement les requêtes de pingback entrantes via xmlrpc.php. Un attaquant peut envoyer une requête pingback.ping élaborée à des milliers de sites WordPress, en demandant à chacun d’envoyer une requête HTTP vers une URL victime unique. La victime reçoit un flot volumétrique de requêtes provenant de serveurs WordPress légitimes, rendant le blocage basé sur les IP inefficace. Votre serveur devient simultanément une victime (épuisement des ressources) et un amplificateur d’attaque involontaire.

SSRF via les pingbacks

Le mécanisme de pingback peut être détourné pour une attaque de type Server-Side Request Forgery (SSRF). Un attaquant envoie une requête pingback.ping où l’URL source pointe vers une ressource réseau interne — http://192.168.1.1/admin, par exemple. Le serveur WordPress récupère cette URL depuis l’intérieur du périmètre réseau, exposant potentiellement des services internes qui ne sont pas accessibles publiquement.

Exposition des identifiants en transit

XML-RPC transmet les identifiants dans le corps de la requête POST en texte clair dans l’enveloppe XML. Si votre site n’impose pas HTTPS, les identifiants sont exposés à tout observateur réseau. Même avec TLS, les identifiants sont intégrés dans chaque requête — il n’existe pas de jeton de session ni de flux OAuth pour limiter la fenêtre d’exposition.

Quand conserver xmlrpc.php activé

Désactivez-le par défaut, mais conservez-le activé si votre flux de travail dépend réellement de l’un des éléments suivants :

• Application mobile WordPress (iOS/Android) : L’application officielle utilise XML-RPC pour toutes les opérations de gestion de site sur les installations WordPress auto-hébergées.
• Plugin Jetpack : Plusieurs modules Jetpack — notamment publicize, les notifications push mobiles, et certaines fonctionnalités de statistiques — communiquent via XML-RPC avec les serveurs WordPress.com.
• Clients de blogging de bureau : MarsEdit, Windows Live Writer, et des outils similaires s’appuient exclusivement sur l’API XML-RPC.
• Pipelines de publication automatisés : IFTTT, Zapier, et les scripts personnalisés qui publient du contenu sur WordPress utilisent souvent XML-RPC lorsque l’API REST n’est pas configurée.
• Pingbacks/trackbacks entre sites WordPress : Si les notifications de pingback inter-sites font partie de votre flux de travail éditorial, désactiver xmlrpc.php les supprime.

Si aucun de ces cas ne s’applique, il n’y a aucune raison opérationnelle de laisser le point de terminaison ouvert.

xmlrpc.php vs. l’API REST WordPress

WordPress a introduit l’API REST dans la version 4.7 comme remplacement moderne basé sur des jetons pour XML-RPC. Comprendre les différences vous aide à déterminer si la désactivation de XML-RPC rompt quelque chose de critique.

Si vous créez une nouvelle intégration ou migrez une intégration existante, utilisez l’API REST. Le modèle d’authentification est nettement plus sécurisé, et le point de terminaison est bien plus facile à auditer et à limiter en débit au niveau de l’infrastructure.

Comment désactiver xmlrpc.php dans WordPress

Choisissez la méthode qui correspond à votre niveau d’accès au serveur et à votre tolérance au risque. Les méthodes sont classées du niveau d’application le plus bas au plus élevé au niveau du serveur.

Méthode 1 : Désactiver via un plugin (le plus rapide, sans accès au serveur requis)

Pour les environnements d’hébergement mutualisé ou les sites où vous préférez ne pas modifier les fichiers de configuration du serveur, un plugin est l’option la plus accessible.

Plugins recommandés :

• Disable XML-RPC-API — à usage unique, empreinte minimale, s’active instantanément
• All In One WP Security and Firewall — suite de sécurité plus complète avec des contrôles XML-RPC granulaires

Étapes pour Disable XML-RPC-API :

1. Accédez à Extensions > Ajouter dans votre tableau de bord WordPress.
2. Recherchez « Disable XML-RPC-API » et cliquez sur Installer maintenant, puis sur Activer.
3. Aucune configuration supplémentaire n’est requise — le plugin se connecte à xmlrpc_enabled et retourne false immédiatement à l’activation.

Étapes pour All In One WP Security and Firewall :

1. Après avoir activé le plugin, accédez à WP Security > Pare-feu.
2. Localisez la section XML-RPC.
3. Activez l’option pour bloquer complètement les requêtes XML-RPC.
4. Enregistrez les paramètres.

Limitation : Le blocage basé sur un plugin s’exécute dans le contexte d’exécution PHP de WordPress. Le serveur démarre toujours PHP, charge WordPress et traite la requête avant de la rejeter. Lors d’une attaque intensive, cela consomme du CPU et de la mémoire. Pour les sites à fort trafic sous attaque active, utilisez plutôt la méthode .htaccess ou Nginx.

Méthode 2 : Désactiver via .htaccess (Apache — Blocage au niveau du serveur)

Le blocage au niveau de .htaccess empêche l’exécution de PHP pour toutes les requêtes ciblant xmlrpc.php. C’est nettement plus efficace sous charge.

1. Connectez-vous à votre serveur via FTP, SFTP, ou le gestionnaire de fichiers de votre hébergeur et ouvrez le fichier .htaccess dans votre répertoire racine WordPress (généralement public_html/.htaccess).
2. Ajoutez le bloc suivant. Placez-le avant les règles de réécriture WordPress standard :

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Enregistrez le fichier.

Pour vérifier que le blocage est actif, exécutez un test depuis votre machine locale :

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Vous devriez recevoir une réponse 403. Une réponse 200 ou 405 signifie que le blocage n’est pas encore en vigueur.

Cas particulier — si vous avez encore besoin de pingbacks depuis des IP de confiance spécifiques, vous pouvez les mettre en liste blanche :

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Méthode 3 : Désactiver via la configuration Nginx

Si votre serveur utilise Nginx (courant dans les environnements d’hébergement VPS), les fichiers .htaccess n’ont aucun effet. Ajoutez le bloc directement dans la configuration du bloc serveur de votre site.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

La directive return 444 ferme la connexion TCP sans envoyer de réponse HTTP, ce qui est plus efficace qu’un 403 car elle empêche le client de l’attaquant de recevoir tout retour d’information. Après modification, rechargez Nginx :

sudo nginx -t && sudo systemctl reload nginx

Placez ce bloc location à l’intérieur de votre bloc server {}, avant toute directive try_files ou de traitement PHP.

Méthode 4 : Désactiver via functions.php (hook de filtre WordPress)

Cette méthode utilise un filtre WordPress pour désactiver XML-RPC au niveau de la couche applicative. Elle est moins efficace que le blocage au niveau du serveur, mais utile lorsque vous n’avez pas d’accès direct au serveur et souhaitez une solution basée sur le code sans dépendance à un plugin.

1. Accédez à Apparence > Éditeur de thème dans votre tableau de bord WordPress, ou accédez directement au fichier via SFTP à wp-content/themes/your-theme/functions.php.
2. Ajoutez ce qui suit à la fin du fichier :

// Disable XML-RPC completely
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Enregistrez le fichier.

Mise en garde importante : Ce filtre désactive les méthodes XML-RPC authentifiées, mais il ne bloque pas la méthode pingback.ping et n’empêche pas l’accès au fichier. Le serveur traite toujours la requête jusqu’au point où WordPress évalue le filtre. Pour une protection complète, combinez ceci avec le blocage .htaccess ou Nginx.

Si vous utilisez un thème enfant, ajoutez toujours le code personnalisé dans le fichier functions.php du thème enfant, et non dans le thème parent. Les mises à jour du thème parent écraseront vos modifications.

Méthode 5 : Désactivation sélective — Bloquer uniquement les pingbacks

Si vous avez besoin de XML-RPC pour Jetpack ou la publication mobile mais souhaitez éliminer le vecteur d’amplification DDoS, vous pouvez désactiver uniquement la méthode de pingback tout en conservant le reste de l’API fonctionnel.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Ajoutez ceci dans le fichier functions.php de votre thème enfant ou dans un plugin spécifique au site. Il s’agit de la configuration recommandée pour les sites qui utilisent Jetpack mais n’ont pas besoin de recevoir des pingbacks.

Comment réactiver xmlrpc.php

Annuler l’une des méthodes ci-dessus restaure l’accès XML-RPC :

• Méthode par plugin : Désactivez ou supprimez le plugin de blocage depuis Extensions > Extensions installées.
• Méthode .htaccess : Supprimez le bloc <Files "xmlrpc.php"> de .htaccess et enregistrez.
• Méthode Nginx : Supprimez le bloc location = /xmlrpc.php de votre configuration serveur et rechargez Nginx avec sudo systemctl reload nginx.
• Méthode functions.php : Supprimez la ligne add_filter( 'xmlrpc_enabled', '__return_false' ) et enregistrez.

Après la réactivation, vérifiez que le point de terminaison répond correctement :

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Une réponse XML valide listant les méthodes disponibles confirme que le point de terminaison est actif.

Renforcer xmlrpc.php sans le désactiver

Si la désactivation n’est pas envisageable, appliquez ces mesures d’atténuation pour réduire la surface d’attaque :

Imposer HTTPS : Assurez-vous que votre site utilise un certificat TLS valide. Si ce n’est pas encore fait, configurez-en un via votre hébergeur — les Certificats SSL empêchent l’interception des identifiants en transit.

Limiter le débit au niveau du pare-feu ou du CDN : Configurez votre WAF (Cloudflare, ModSecurity) pour limiter les requêtes POST vers xmlrpc.php à un maximum de 5 à 10 par minute par IP.

Bloquer system.multicall spécifiquement :

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

Cela élimine le vecteur d’amplification par force brute tout en préservant toutes les autres fonctionnalités XML-RPC.

Restreindre par IP : Si vous accédez à XML-RPC uniquement depuis des adresses IP connues (la plage IP de l’opérateur de votre application mobile, ou une IP de bureau fixe), mettez ces adresses en liste blanche dans .htaccess ou Nginx et refusez toutes les autres.

Surveiller les journaux d’accès : Auditez régulièrement les journaux de votre serveur pour détecter les requêtes POST répétées vers xmlrpc.php. Une augmentation soudaine des requêtes POST avec un statut 200 vers ce fichier est un indicateur fiable d’une campagne de force brute en cours.

Sur un VPS avec cPanel ou tout autre environnement de panneau de contrôle géré, vous pouvez configurer les règles ModSecurity directement depuis le panneau de contrôle pour appliquer ces restrictions sans modification manuelle des fichiers.

Choisir la bonne méthode : matrice de décision

Pour les sites de production hébergés sur des Serveurs Dédiés, le blocage au niveau du serveur Nginx ou Apache est toujours préférable à une solution basée sur un plugin, car il empêche entièrement l’exécution de PHP pour les requêtes malveillantes, éliminant ainsi la surcharge CPU que le blocage par plugin engendre lors d’attaques soutenues.

Liste de contrôle pratique des points essentiels

• Vérifiez si un plugin ou service actif dans votre environnement nécessite réellement XML-RPC avant de le désactiver — vérifiez Jetpack, les applications mobiles et tous les outils d’automatisation de publication.
• Si aucune dépendance n’existe, appliquez le blocage au niveau du serveur (.htaccess ou Nginx) plutôt qu’un plugin — c’est plus efficace et résiste à la désactivation des plugins.
• Si vous devez conserver XML-RPC actif, supprimez inconditionnellement system.multicall et pingback.ping via le filtre xmlrpc_methods — ces deux méthodes représentent la grande majorité des abus XML-RPC.
• Imposez toujours HTTPS sur tout site WordPress qui accepte des requêtes authentifiées, y compris XML-RPC.
• Après avoir appliqué un blocage, vérifiez avec curl que le point de terminaison retourne 403 ou abandonne la connexion — ne supposez pas que la configuration est correcte sans la tester.
• Dans les environnements VPS ou serveur dédié basés sur Nginx, utilisez return 444 plutôt que deny all pour éviter de donner aux attaquants tout retour au niveau HTTP.
• Journalisez et surveillez les requêtes POST vers xmlrpc.php — une augmentation soudaine est un signal d’alerte précoce d’une campagne de credential stuffing ou d’amplification DDoS.
• Si vous gérez plusieurs sites WordPress, envisagez de centraliser cette configuration au niveau du serveur ou du CDN plutôt que d’appliquer des règles de plugin par site.

Pour les sites nécessitant une gestion à distance robuste sans la surface de risque XML-RPC, la migration des intégrations vers l’API REST WordPress avec des mots de passe d’application est la voie correcte à long terme. L’API REST offre la révocation par jeton, des permissions délimitées et des sémantiques HTTP standard qui sont bien plus faciles à sécuriser et à auditer.

Si vous configurez un nouvel environnement WordPress et souhaitez une base propre et sécurisée dès le départ, les Panneaux de contrôle VPS avec ModSecurity préconfiguré vous offrent une protection WAF au niveau du serveur sans nécessiter la rédaction manuelle de règles.

—

Questions fréquemment posées

La désactivation de xmlrpc.php casse-t-elle l’API REST WordPress ?

Non. L’API REST (/wp-json/) est un point de terminaison complètement séparé avec sa propre authentification et son propre routage. Bloquer xmlrpc.php n’a aucun effet sur les fonctionnalités de l’API REST. Les deux systèmes sont architecturalement indépendants.

La désactivation de xmlrpc.php cassera-t-elle Jetpack ?

Cela dépend des modules Jetpack que vous utilisez. Jetpack a progressivement migré ses fonctionnalités vers l’API REST, mais certains modules plus anciens — notamment certaines fonctionnalités de publicize et de notifications — communiquent encore via XML-RPC. Consultez la page de débogage Jetpack dans Jetpack > Tableau de bord > Débogage pour vérifier si la connectivité XML-RPC est listée comme une exigence avant de la désactiver.

La méthode .htaccess ou la méthode functions.php est-elle plus sécurisée ?

La méthode .htaccess est nettement plus sécurisée dans des conditions d’attaque. Elle bloque la requête au niveau du serveur web avant le chargement de PHP, consommant un minimum de ressources. Le filtre functions.php s’exécute dans le contexte d’exécution PHP de WordPress, ce qui signifie que le serveur démarre toujours WordPress pour chaque requête bloquée — ce qui est coûteux lors d’une attaque à volume élevé.

Un attaquant peut-il encore exploiter xmlrpc.php si je le désactive uniquement via le filtre WordPress ?

Partiellement. Le filtre xmlrpc_enabled empêche les appels de méthodes authentifiées, mais le fichier reste accessible publiquement et le serveur traite toujours les requêtes entrantes. Le point de terminaison de pingback peut rester partiellement fonctionnel selon la version de WordPress. Pour une protection complète, associez le filtre à un blocage au niveau du serveur.

Comment vérifier si xmlrpc.php est actuellement accessible sur mon site ?

Exécutez la commande suivante depuis votre terminal local, en remplaçant le domaine par le vôtre :

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Une réponse 200 signifie que le point de terminaison est ouvert. Un 403 ou une interruption de connexion (000) confirme qu’il est bloqué. Vous pouvez également utiliser l’outil en ligne sur xmlrpc.eritreo.it pour tester spécifiquement la vulnérabilité aux pingbacks.