Chaque site WordPress stocke à sa racine un fichier «silencieux» que la plupart des propriétaires ne découvrent qu’après une attaque. Son nom: xmlrpc.php. Le fichier en lui-même n’a rien de malveillant: WordPress indique honnêtement qu’il s’agit d’une interface pour les interactions à distance. Mais c’est par ce fichier que des robots tentent depuis des années des attaques par force brute sur les mots de passe, envoient des pingbacks indésirables et génèrent du trafic DDoS.

D’après les données de Wordfence pour 2024, les attaques via XML-RPC figurent parmi les cinq principaux vecteurs d’attaque contre les sites WordPress. Une seule requête system.multicall permet à un attaquant de tester des centaines de mots de passe à la fois, au lieu d’un seul comme via le formulaire de connexion. Les hébergeurs enregistrent des millions de tentatives de ce type chaque mois sur un site moyen.

Voyons ensemble pourquoi ce fichier existe, qui devrait le conserver et, surtout, découvrons cinq façons de désactiver ou de bloquer xmlrpc.php de manière sécurisée, de l’extension en un clic aux modifications ciblées du fichier .htaccess.

💡 Aperçu rapide:

• Comprendre ce qu’est xmlrpc.php et quelles fonctions WordPress en dépendent (pingback, application mobile, Jetpack)
• Évaluer les risques réels: amplification par force brute, DDoS par pingback et balayage des répertoires par des robots
• Choisir la bonne méthode de protection: désactivation via une extension, blocage par .htaccess, fermeture de l’accès au niveau du serveur web ou suppression du fichier
• Mettre en place une surveillance: comment s’assurer que xmlrpc.php ne répond plus aux requêtes

Qu’est-ce que xmlrpc.php et quelles fonctions WordPress en dépendent

XML-RPC est un protocole d’appel de procédure à distance qui fonctionne via HTTP et transmet les données au format XML. Cette technologie est apparue à la fin des années 1990, bien avant l’API REST, et WordPress en a hérité à ses débuts. Le fichier xmlrpc.php situé à la racine du site accepte les requêtes XML, les traite et renvoie une réponse, par exemple pour publier un article, téléverser un fichier multimédia ou vérifier les droits d’un utilisateur.

En pratique, plusieurs scénarios passent par xmlrpc.php:

• Pingbacks et trackbacks. Lorsque quelqu’un crée un lien vers votre article, son site envoie une requête XML-RPC avec une notification. Votre WordPress vérifie le lien et, s’il est réel, ajoute le pingback aux commentaires.

• Publication à distance. Des applications comme l’ancien Windows Live Writer ou des clients de bureau (TextMate, MarsEdit) utilisaient XML-RPC pour rédiger et envoyer des articles sans passer par l’interface d’administration.

• Application mobile WordPress. L’application officielle iOS et Android s’est longtemps appuyée sur XML-RPC, même si elle migre de plus en plus vers l’API REST aujourd’hui.

• Intégrations. Des services comme Jetpack (une partie de ses fonctionnalités), IFTTT et certains outils SEO utilisent encore XML-RPC pour se connecter au site.

Avec la sortie de l’API REST de WordPress dans la version 4.7 (décembre 2016), la plupart des intégrations modernes sont passées au nouveau protocole. L’API REST est plus rapide, fonctionne avec du JSON au lieu du XML et est mieux documentée. Néanmoins, WordPress inclut toujours xmlrpc.php dans chaque installation pour des raisons de compatibilité ascendante.

Nuance importante: depuis WordPress 2.6 (en 2008), la fonctionnalité de publication à distance via XML-RPC est désactivée par défaut. Pour l’activer, vous devez cocher explicitement la case dans «Réglages → Rédaction». Les pingbacks et trackbacks continuent de fonctionner en parallèle.

En quoi xmlrpc.php est dangereux: trois principaux vecteurs d’attaque

Les développeurs de WordPress ont corrigé xmlrpc.php à plusieurs reprises. Dans la version 2.1.2, un utilisateur authentifié avec le rôle «contributeur» pouvait publier un article en contournant les restrictions. Dans la version 2.3.1, une fuite d’information via XML-RPC a été découverte. Ces deux failles ont été rapidement corrigées, mais le protocole lui-même est resté structurellement vulnérable à trois catégories d’attaques qui sont toujours d’actualité en 2026.

Amplification par force brute via system.multicall

Le principal problème est la méthode system.multicall. Elle permet de regrouper plusieurs appels wp.getUsersBlogs dans une seule requête HTTP. Chaque appel vérifie un couple «identifiant + mot de passe». Ainsi, au lieu d’une seule tentative par requête, l’attaquant en effectue des centaines. Cloudflare a enregistré des pics de plusieurs dizaines de milliers de requêtes de ce type par heure sur un seul site.

Le formulaire de connexion classique wp-login.php est limité à une tentative par essai et se protège facilement avec une extension comme Wordfence ou Limit Login Attempts. xmlrpc.php contourne tous ces limiteurs car il fonctionne via un point de terminaison différent.

DDoS par pingback

La fonctionnalité de pingback est conçue comme une notification inoffensive. Mais un attaquant peut envoyer de fausses requêtes de pingback au nom de centaines de sites, et votre serveur ira vérifier chaque «lien», sollicitant le processeur, le réseau et la base de données. À une échelle suffisante, le site tombe. Sucuri, dans son rapport de 2023, qualifie les attaques par pingback comme l’un des vecteurs de DDoS les plus courants contre WordPress.

Balayage des répertoires par des robots

Les robots recherchent xmlrpc.php non seulement à la racine, mais aussi dans des sous-répertoires inventés comme /2026/01/xmlrpc.php et /blog/xmlrpc.php. Chacune de ces requêtes renvoie une erreur 404 et gaspille les ressources du serveur. Même si l’attaque échoue, des dizaines de milliers de requêtes inutiles ralentissent le site et saturent les journaux. En pratique, les propriétaires voient les graphiques de cPanel passer dans le rouge, et la raison en est précisément le balayage de xmlrpc.php par des robots.

5 Façons de désactiver ou de sécuriser xmlrpc.php

Voici cinq méthodes, de la plus simple à la plus radicale. Choisissez en fonction de votre situation: si vous utilisez l’application mobile, si vous avez besoin des pingbacks, quel hébergement vous avez.

1. Désactiver via une extension

La voie la plus sûre pour ceux qui ne veulent pas toucher au code. Installez une extension, et elle bloquera l’accès à xmlrpc.php au niveau de WordPress, avant le début du traitement de la requête.

Avantages: pas besoin de modifier .htaccess ou functions.php, facile à réactiver. Inconvénients: ajoute une extension supplémentaire dans l’administration, la protection disparaît lors de la désactivation.

Quelques options éprouvées:

• Disable XML-RPC, minimaliste, une seule action: activée, et l’accès est fermé. Aucun réglage.
• Wordfence Security, pare-feu complet dans lequel la désactivation de XML-RPC n’est qu’une des fonctions. Convient si vous utilisez déjà Wordfence ou prévoyez de l’installer.

2. Bloquer via.htaccess

Si vous travaillez sur un serveur Apache, le fichier .htaccess à la racine du site vous permet de bloquer l’accès avant que la requête n’atteigne WordPress. Cela réduit la charge: Apache renvoie immédiatement une erreur 403 Forbidden, sans lancer PHP.

Ajoutez le bloc suivant au .htaccess au début du fichier, avant # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

La directive RedirectMatch 403 intercepte toute URL se terminant par /xmlrpc.php, y compris les sous-répertoires comme /2025/06/xmlrpc.php, et renvoie instantanément une erreur 403.

Avantages: ne touche pas au code de WordPress, fonctionne avant le chargement de PHP, économise des ressources. Inconvénients: nécessite de modifier .htaccess manuellement, le fichier peut être écrasé lors d’un changement d’hébergement ou de thème.

Important: avant de modifier .htaccess, faites une sauvegarde. Une erreur de syntaxe dans .htaccess peut faire tomber le site (500 Internal Server Error).

3. Supprimer les liens via functions.php

Cette méthode ne bloque pas le fichier lui-même, mais supprime les liens HTML vers xmlrpc.php et wlwmanifest.xml de la section <head> du site. L’avantage est une visibilité réduite: les robots qui analysent le HTML ne voient pas de pointeur direct vers le point de terminaison XML-RPC.

Ajoutez au fichier functions.php du thème actif (ou via l’extension Code Snippets):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

Le hook rsd_link génère <link rel="EditURI">, un lien vers xmlrpc.php pour les clients Really Simple Discovery. Le hook wlwmanifest_link est destiné à Windows Live Writer (abandonné depuis longtemps, mais WordPress le génère toujours).

Avantages: un <head> propre, sans liens inutiles. Inconvénients: xmlrpc.php reste physiquement accessible via une URL directe, il ne s’agit pas d’un blocage mais d’un masquage.

4. Fermer l’accès via un WAF ou Cloudflare

Un pare-feu applicatif web (WAF) bloque les requêtes vers xmlrpc.php avant qu’elles n’atteignent votre serveur. C’est l’approche la plus efficace pour les sites sur n’importe quel hébergement.

Options de configuration:

• Cloudflare (offre gratuite): Règle WAF → Bloquer → Le champ URI Path contient /xmlrpc.php. La requête est rejetée au niveau du réseau Cloudflare, votre serveur ne la voit même pas.
• Wordfence WAF: Fonction intégrée «Disable XML-RPC» dans la section pare-feu.
• WAF de l’hébergeur: Kinsta, WP Engine et d’autres hébergeurs managés vous permettent de désactiver XML-RPC en quelques clics via le panneau de contrôle.

Avantages: charge serveur nulle, possibilité de réglage fin (par exemple, autoriser Jetpack tout en bloquant tout le reste). Inconvénients: nécessite une configuration côté WAF, tous les hébergeurs ne proposent pas cette fonctionnalité.

5. Supprimer ou renommer le fichier lui-même

La méthode la plus radicale. Vous supprimez (ou renommez) le fichier xmlrpc.php du serveur. Si le fichier n’existe pas physiquement, il n’y a rien pour traiter les requêtes, le serveur renvoie une erreur 404.

Nuance importante: lors de la prochaine mise à jour de WordPress, le fichier sera restauré. Les mises à jour automatiques du cœur écrasent tous les fichiers WordPress, y compris xmlrpc.php. La suppression est donc une mesure temporaire, à moins de mettre en place un nettoyage régulier.

Si vous optez pour cette voie, complétez la suppression par la règle .htaccess de la méthode 2. Sans cela, les robots continueront à frapper à l’URL xmlrpc.php, et le serveur renverra honnêtement une erreur 404 à chaque requête, générant des milliers d’erreurs dans les journaux.

Faut-il vraiment désactiver xmlrpc.php?

La réponse dépend de ce que vous utilisez. Parcourez la liste de contrôle:

Si vous n’utilisez pas une ancienne version de l’application mobile, si vous n’avez pas activé la gestion Jetpack avec WordPress.com et si les pingbacks ne sont pas essentiels pour vous, désactivez-le sans hésiter. En 2026, l’API REST couvre la quasi-totalité des scénarios réels.

Vidéo: comment désactiver XML-RPC dans WordPress en 5 minutes

Regardez un guide visuel pour désactiver xmlrpc.php, avec une démonstration à l’écran et l’explication de chaque méthode:

⁉️🤔 Foire aux questions

Est-il prudent d’ignorer simplement xmlrpc.php?

Dans la plupart des cas, non. Même si vous n’utilisez pas XML-RPC, les robots analysent ce point de terminaison en permanence. Chacune de ces requêtes sollicite le serveur. Il est préférable de fermer explicitement l’accès via .htaccess ou une extension, cela élimine à la fois le risque de force brute et les requêtes inutiles dans les journaux.

Le site va-t-il cesser de fonctionner si xmlrpc.php est désactivé?

WordPress lui-même continuera à fonctionner sans changement. Vérifiez simplement si vous utilisez la gestion Jetpack avec WordPress.com ou une ancienne version de l’application mobile. Si ce n’est pas le cas, désactivez sans crainte. Les pingbacks cesseront d’arriver, mais la plupart des sites ne les utilisent de toute façon pas pour une véritable communication.

Comment vérifier que xmlrpc.php est effectivement bloqué?

Ouvrez dans votre navigateur https://your-site.com/xmlrpc.php. Si vous voyez une page blanche avec le message «XML-RPC server accepts POST requests only», le fichier est actif et répond. Si vous obtenez une erreur 403 Forbidden ou 404 Not Found, le blocage fonctionne. Pour une surveillance automatique, vous pouvez utiliser des vérificateurs en ligne comme xmlrpc.eror.xyz ou une requête curl depuis la console.

Qu’est-ce qui est préférable: une extension ou.htaccess ?

.htaccess bloque la requête avant le lancement de WordPress, ce qui économise les ressources du serveur. Une extension est plus facile à installer et ne nécessite pas de modifier des fichiers. Pour les sites non critiques, il n’y a quasiment aucune différence. Pour les projets à forte charge, .htaccess ou une règle WAF est préférable.

Dois-je mettre à jour WordPress après avoir désactivé xmlrpc.php?

Non. La désactivation de xmlrpc.php ne dépend pas de la version de WordPress et n’affecte pas les mises à jour du cœur. Seule nuance: si vous avez supprimé le fichier physiquement, la mise à jour le restaurera, ce qui nécessitera une nouvelle suppression.

Alors, que faire de xmlrpc.php sur votre site?

Il n’y a pas de réponse universelle, tout dépend du contexte. Mais la pratique de milliers de sites WordPress donne une image claire: si vous ne savez pas si vous avez besoin de XML-RPC, c’est que vous n’en avez pas besoin.

Vous voulez de la fiabilité sans plonger dans le code, installez Disable XML-RPC. Vous êtes prêt à consacrer cinq minutes au .htaccess, obtenez une protection au niveau du serveur sans extension supplémentaire. Vous utilisez Cloudflare, configurez une règle WAF et oubliez le problème.

L’essentiel est de ne pas laisser xmlrpc.php ouvert «par défaut». En 2026, chaque point de terminaison WordPress non fermé est une cible pour les robots automatisés, peu importe que vous ayez un blog ou une boutique en ligne. Fermez l’accès en utilisant l’une des méthodes ci-dessus, vérifiez le résultat avec une requête curl et dormez sur vos deux oreilles.