Saviez-vous que selon les données de Wordfence, XML-RPC est impliqué dans des milliards de tentatives d’attaques chaque année contre des sites WordPress ? Cette interface héritée, introduite dans WordPress 3.5 en 2012, reste activée par défaut sur toutes les installations — même si la majorité des utilisateurs ignorent son existence.
XML-RPC (XML Remote Procedure Call) a été conçu pour permettre la publication de contenu à distance depuis des applications mobiles ou des outils tiers. Mais en 2026, cette fonctionnalité est largement obsolète : l’API REST WordPress la remplace avantageusement, tandis que xmlrpc.php demeure une surface d’attaque active et dangereuse.
Dans ce guide complet, vous apprendrez :
XML-RPC est un protocole de communication utilisant le format XML pour encoder des appels de fonctions et HTTP comme mécanisme de transport. Dans WordPress, il se matérialise par le fichier xmlrpc.php situé à la racine de votre installation.
À l’origine, ce système permettait :
Aujourd’hui, l’application mobile officielle WordPress utilise exclusivement l’API REST. Les outils modernes ont suivi la même évolution. Résultat : la quasi-totalité des sites WordPress peuvent désactiver XML-RPC sans aucun impact fonctionnel.
La méthode system.multicall de XML-RPC permet d’exécuter des centaines de tentatives d’authentification en une seule requête HTTP. Là où une attaque classique sur wp-login.php nécessite une requête par tentative, XML-RPC permet de tester 500 à 1 000 combinaisons identifiant/mot de passe en un seul appel.
Cette amplification rend les attaques quasi indétectables par les systèmes classiques de limitation de débit. Selon les analyses de Wordfence, des campagnes coordonnées via XML-RPC ont ciblé jusqu’à 1,4 million de sites WordPress simultanément, générant plusieurs milliards de requêtes en quelques heures.
La fonctionnalité de pingback XML-RPC peut transformer votre site en vecteur d’attaque DDoS involontaire. Des attaquants envoient des pingbacks falsifiés à des milliers de sites WordPress vulnérables en pointant vers une cible. Chaque site envoie alors une requête vers cette cible, créant un effet d’amplification massif.
Votre site participe ainsi à des attaques contre des tiers, ce qui peut entraîner son blacklistage par les hébergeurs et pare-feux. Plusieurs entrées CVE documentées sur NVD NIST et sur CVE MITRE concernent directement l’exploitation des pingbacks WordPress.
Si vous avez mis en place une authentification à deux facteurs (2FA) sur votre page de connexion, sachez que XML-RPC ignore fréquemment ces protections. Un attaquant peut s’authentifier directement via xmlrpc.php sans jamais passer par la page de login sécurisée, contournant ainsi votre 2FA.
C’est l’une des raisons pour lesquelles la sécurisation de WordPress ne peut pas reposer sur un seul point d’entrée. Consultez notre guide complet sur comment sécuriser la connexion WordPress pour une approche multi-couches.
La méthode la plus directe consiste à envoyer une requête de test à votre fichier xmlrpc.php :
curl -X POST https://votresite.com/xmlrpc.php \
-H "Content-Type: text/xml" \
-d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Résultats possibles :
Des services comme xmlrpc.click permettent de tester votre URL en quelques secondes sans ligne de commande.
Ajoutez ces lignes dans votre fichier .htaccess à la racine de WordPress :
# Désactiver XML-RPC
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Cette méthode bloque l’accès au niveau du serveur web, avant même l’exécution de PHP. C’est la méthode la plus efficace car elle ne consomme aucune ressource lors des tentatives d’attaque.
Si votre hébergeur utilise Nginx, ajoutez dans votre bloc server :
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Ajoutez ce code dans le fichier functions.php de votre thème enfant ou d’un plugin personnalisé :
<?php
// Désactiver XML-RPC
add_filter('xmlrpc_enabled', '__return_false');
// Supprimer les en-têtes de découverte XML-RPC
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
?>Attention : cette méthode désactive XML-RPC au niveau PHP mais le fichier reste accessible. Les requêtes arrivent toujours jusqu’au serveur et consomment des ressources. Préférez les méthodes .htaccess ou Nginx pour un blocage optimal.
Si vous utilisez déjà Wordfence ou un équivalent, l’option de blocage XML-RPC se trouve généralement dans les paramètres de pare-feu. L’avantage : vous bénéficiez d’une journalisation des tentatives, utile pour l’audit de sécurité.
D’autres plugins dédiés comme Disable XML-RPC ou Stop XML-RPC Attack proposent une désactivation en un clic avec options de blocage des pingbacks.
Si XML-RPC est encore nécessaire pour un usage spécifique, restreignez l’accès aux seules IP de confiance :
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 203.0.113.1 # Remplacez par votre IP
</Files>Dans de rares cas, XML-RPC reste nécessaire :
Dans ces cas, la restriction par IP (méthode 5) est préférable à une désactivation totale. Pour les nouveaux projets, migrez systématiquement vers l’API REST WordPress.
Non. L’application mobile officielle WordPress (iOS et Android) utilise l’API REST depuis plusieurs années. Désactiver XML-RPC n’a aucun impact sur son fonctionnement.
Les plugins modernes (UpdraftPlus, BlogVault, BackupBuddy) n’utilisent pas XML-RPC. En cas de doute, désactivez XML-RPC et vérifiez que vos sauvegardes s’exécutent normalement. Si tout fonctionne, le blocage est sans conséquence.
XML-RPC désactivé élimine un vecteur majeur, mais wp-login.php reste une cible. Combinez le blocage de XML-RPC avec une authentification à deux facteurs et une limitation des tentatives de connexion. Retrouvez l’ensemble des mesures dans nos bonnes pratiques de sécurité WordPress.
Consultez vos logs d’accès serveur (access.log). Recherchez des requêtes POST répétées vers /xmlrpc.php depuis la même adresse IP. Des centaines de requêtes en quelques minutes constituent un signal d’attaque évident. Selon les données de Patchstack, 74 % des attaques sur WordPress ciblent des vecteurs non protégés par l’hébergeur — XML-RPC en fait partie.
En 2026, désactiver XML-RPC WordPress est l’une des mesures de durcissement les plus efficaces par rapport à sa complexité d’implémentation. En quelques lignes de configuration, vous éliminez une surface d’attaque impliquée dans des milliards de tentatives d’intrusion chaque année.
Plan d’action immédiat :
.htaccess ou votre configuration NginxVous souhaitez aller plus loin ? SecuriteWP propose un audit et une sécurisation complète de votre site WordPress, incluant la vérification de tous les vecteurs d’attaque connus. Contactez-nous pour un audit gratuit →
Découvrez comment implémenter une Content Security Policy (CSP) sur WordPress pour bloquer les attaques XSS. Guide complet 2026 avec directives, exemples de code et dépannage.
Les attaques supply chain WordPress ciblent la chaîne de distribution des plugins et thèmes. Découvrez comment elles fonctionnent, les IOC à surveiller et les mesures concrètes pour protéger votre site.
Votre base de données MySQL est le cœur de WordPress : elle contient tout. Découvrez comment la sécuriser avec 8 techniques concrètes pour 2026.
Découvrez quelles permissions de fichiers appliquer sur WordPress (644, 755, 600) pour sécuriser votre installation et éviter les intrusions. Guide complet 2026 avec commandes SSH.
Apprenez à configurer les bonnes permissions de fichiers WordPress (chmod 755/644/640). Guide complet SSH, FTP, WP-CLI pour sécuriser votre site contre les intrusions.
Un backdoor CVSS 10 découvert dans Smart Slider 3 PRO 3.5.1.35 et deux failles XSS dans Gravity Forms 2.9.30 : analyse et mesures d’urgence pour protéger votre site WordPress.
Nos experts français assurent un support et une prestation de qualité.
