Prise en charge en cours Lun–Ven · 9h–19h
Signaler un incident
P.03 P.02

xmlrpc.php WordPress : pourquoi on le désactive et quand on ne peut pas

xmlrpc.php WordPress : pourquoi on le désactive et quand on ne peut pas

xmlrpc.php est un fichier présent dans toutes les installations WordPress depuis la version 3.5. Il expose une API XML-RPC qui permettait à des applications tierces de publier du contenu, gérer des commentaires, ou contrôler le site à distance avant que l'API REST WordPress existe. En 2026, sur la quasi-totalité des sites, ce fichier ne sert plus à rien d'utile. Mais il reste actif par défaut, et les attaquants l'utilisent activement.

Définition en une phrase

xmlrpc.php est un fichier WordPress qui expose un protocole API ancien (XML-RPC) permettant de contrôler le site depuis des applications tierces, aujourd'hui remplacé par l'API REST native de WordPress mais encore utilisé comme vecteur d'attaque par brute force et amplification de requêtes.

En clair, pour les non-initiés. Imaginez une porte de service à l'arrière de votre bâtiment qui n'est plus utilisée depuis des années. Personne n'a pris la peine de la fermer. Les cambrioleurs connaissent l'existence de cette porte, testent régulièrement si elle est ouverte, et s'y engouffrent quand c'est le cas. C'est xmlrpc.php pour WordPress.

Pourquoi xmlrpc.php est dangereux

Amplification de brute force. L'API XML-RPC permet d'envoyer une seule requête HTTP contenant des centaines ou des milliers de tentatives de connexion imbriquées via la méthode system.multicall. Un attaquant teste 1 000 couples login/mot de passe avec une seule requête, contournant efficacement les mesures de rate limiting sur wp-login.php.

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param><value><array><data>
      <value><struct>
        <member><name>methodName</name><value>wp.getUsersBlogs</value></member>
        <member><name>params</name><value><array><data>
          <value>admin</value>
          <value>password123</value>
        </data></array></value></member>
      </struct></value>
      <!-- ... 999 autres tentatives ... -->
    </data></array></value></param>
  </params>
</methodCall>

Charge serveur. Même sans succès d'authentification, le volume de requêtes vers xmlrpc.php peut dégrader les performances. Certains bots scannent des millions de sites WordPress et testent xmlrpc.php sur chacun.

Exploitation de plugins. Certains plugins implémentent leurs propres méthodes XML-RPC. Des CVE documentées utilisent xmlrpc.php comme point d'entrée pour exploiter des vulnérabilités de plugins.

Pingbacks amplifiés. La méthode pingback.ping peut être utilisée pour amplifier des attaques DDoS : un attaquant envoie des pingbacks forgés depuis votre site vers une cible tierce, utilisant votre serveur comme amplificateur.

Sur les sites WordPress que nous auditons, les logs montrent des tentatives d'exploitation de xmlrpc.php sur pratiquement 100 % d'entre eux, plusieurs fois par semaine pour les plus petits sites, plusieurs fois par heure pour les sites à fort trafic.

Quand on peut désactiver xmlrpc.php

Dans la grande majorité des cas. Les fonctionnalités qui dépendaient de XML-RPC ont migré vers l'API REST WordPress :

  • Publication depuis des applications mobiles WordPress : l'app officielle WordPress utilise l'API REST depuis la version 12.9 (2019).
  • Intégrations IFTTT, Zapier, et autres automatisations : toutes supportent l'API REST.
  • Migration de contenu : les outils modernes (WP CLI, WP All Import) n'utilisent pas XML-RPC.

Si vous n'utilisez pas Jetpack, l'application mobile WordPress avec un compte ancien, ou des intégrations tierces qui auraient été configurées avant 2019, xmlrpc.php peut être désactivé sans impact fonctionnel.

Quand on ne peut pas désactiver xmlrpc.php

Jetpack. La majorité des fonctionnalités Jetpack (statistiques, sauvegarde VaultPress, protection brute force Jetpack) utilisent XML-RPC pour communiquer avec les serveurs WordPress.com. Désactiver xmlrpc.php casse Jetpack.

Application mobile WordPress ancienne. Les comptes configurés dans l'app avant la migration vers l'API REST peuvent encore utiliser XML-RPC. Tester la déconnexion/reconnexion dans l'app après désactivation.

Plugins de publication tiers anciens. Des intégrations configurées il y a plusieurs années avec des outils comme Windows Live Writer (abandonné) ou MarsEdit sur Mac. Très rare en 2026.

La bonne question à se poser : "est-ce que quelqu'un utilise réellement xmlrpc.php sur ce site ?" Pour y répondre, on regarde les logs :

grep "xmlrpc.php" /var/log/apache2/access.log | grep -v "404" | awk '{print $1}' | sort | uniq -c | sort -rn

Si les seules IPs qui frappent xmlrpc.php sont des IPs de datacenters et non des IPs connues de l'équipe ou des services tiers légitimes, le fichier ne sert à rien d'utile.

Comment Secushot traite xmlrpc.php en intervention

Dans notre protocole P.03 Durcissement, xmlrpc.php fait partie de la checklist standard WordPress.

Si désactivation possible :

Via .htaccess :

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

Via Cloudflare WAF (si le site est derrière Cloudflare) :

(http.request.uri.path eq "/xmlrpc.php")
Action : Block

La règle Cloudflare est préférable car elle bloque le trafic avant qu'il atteigne votre serveur, sans consommer de ressources Apache/Nginx.

Si désactivation impossible (Jetpack actif) :

On bloque les méthodes XML-RPC dangereuses en laissant passer uniquement les requêtes légitimes Jetpack :

// Dans functions.php
add_filter('xmlrpc_methods', function($methods) {
    // Supprimer system.multicall pour bloquer l'amplification de brute force
    unset($methods['system.multicall']);
    return $methods;
});

Et on restreint les IPs autorisées à appeler xmlrpc.php aux IPs de WordPress.com (plages documentées) via règle Cloudflare.

L'alternative : l'API REST WordPress

L'API REST WordPress (/wp-json/) a remplacé XML-RPC pour l'ensemble des cas d'usage modernes. Elle est mieux documentée, plus sécurisée par défaut, et supporte l'authentification JWT et Application Passwords (WordPress 5.6+).

Si vous avez des intégrations qui utilisent encore XML-RPC, la migration vers l'API REST est le chemin à prendre. Les intégrations modernes (Zapier, n8n, outils d'import/export) sont toutes compatibles API REST.

Les erreurs qu'on rencontre le plus souvent

1. Bloquer xmlrpc.php uniquement sur wp-admin et oublier le fichier direct

Une règle qui protège /wp-admin/ ne protège pas /xmlrpc.php qui est à la racine. On vise le fichier directement.

2. Désactiver xmlrpc.php via plugin de sécurité

Certains plugins WordPress proposent de "désactiver" XML-RPC via un filtre PHP. C'est moins fiable qu'un blocage au niveau du serveur ou de Cloudflare : si le plugin est temporairement désactivé (mise à jour ratée, conflit), xmlrpc.php redevient accessible. On préfère le blocage au niveau serveur ou WAF.

3. Croire que Wordfence gère xmlrpc.php

Wordfence protège contre certaines exploitations de xmlrpc.php, mais les requêtes arrivent quand même jusqu'au serveur et consomment des ressources. Le blocage en amont (Cloudflare ou .htaccess) est plus efficace en termes de performance.

4. Ne pas vérifier que Jetpack fonctionne après désactivation

Sur des sites où Jetpack est actif mais peu utilisé (souvent installé par une agence et jamais configuré), on désactive xmlrpc.php et on observe. Si des fonctionnalités Jetpack tombent, on ajuste. Ne jamais supposer sans vérifier.

Questions fréquentes

Désactiver xmlrpc.php améliore-t-il les performances ? Sur les sites sous attaque active, oui. Les tentatives de brute force via xmlrpc.php génèrent des requêtes PHP qui chargent WordPress en entier. Bloquer avant le serveur (Cloudflare ou .htaccess) libère ces ressources pour les vrais visiteurs.

xmlrpc.php existe-t-il sur PrestaShop, Magento, Shopify ? Non. C'est spécifique à WordPress. PrestaShop et Magento exposent leurs propres APIs avec leurs propres vecteurs d'attaque. Shopify est un SaaS géré, l'accès au filesystem n'est pas un risque client.

Mon site WordPress a-t-il xmlrpc.php actif ? Tester : curl -s https://votre-domaine.fr/xmlrpc.php. Si la réponse est XML-RPC server accepts POST requests only., le fichier est actif et accessible.

Bloquer xmlrpc.php suffit-il à protéger wp-login.php ? Non. wp-login.php est un vecteur d'attaque distinct. Un rate limiting sur wp-login.php et une règle WAF pour bloquer les IPs qui échouent plusieurs fois sont nécessaires en complément. Les deux vecteurs sont traités dans notre P.03.

xmlrpc.php peut-il être utilisé pour déposer des fichiers sur le serveur ? Certaines vulnérabilités de plugins qui implémentent des méthodes XML-RPC personnalisées ont permis des uploads de fichiers. C'est un vecteur d'entrée pour des webshells documenté sur des CVE de plugins anciens. C'est une raison supplémentaire de désactiver xmlrpc.php sur les sites sans besoin réel.

Pour aller plus loin

xmlrpc.php actif sur votre WordPress et vous voulez fermer ce vecteur ? Notre durcissement sécurité (P.03, 790 € TTC, livré en 72 h) traite xmlrpc.php, wp-login.php, les headers HTTP, TLS et le WAF Cloudflare en une intervention complète. Rapport PDF avant/après. Briefer un durcissement P.03

Dernière mise à jour · 22 avril 2026 ← Retour au lexique