Votre site est lent, votre hébergeur vous envoie des avertissements de dépassement de limites et les journaux affichent un flux incessant de requêtes POST vers xmlrpc.php. Si vous administrez WordPress, ce cauchemar vous est probablement familier.

Le fichier xmlrpc.php est un élément discret mais extrêmement dangereux de toute installation WordPress. Il réside à la racine de votre site depuis l'installation du CMS et reste depuis des décennies un point d'entrée privilégié pour les robots et les attaquants. Selon le rapport Wordfence 2024, les attaques XML-RPC figurent parmi les cinq principaux vecteurs de menace pour les sites WordPress, et rien n'a changé en 2026.

Pourtant, la plupart des propriétaires de sites ignorent pourquoi ce fichier existe ou comment le neutraliser. Ce guide présente quatre méthodes opérationnelles pour bloquer xmlrpc.php, d'une simple règle .htaccess à un pare-feu au niveau CDN. Pas de superflu, uniquement du code testé et des explications sur le moment d'utiliser chaque méthode.

💡 Aperçu rapide:

• Vérifiez si votre xmlrpc.php répond aux requêtes POST (c'est probablement le cas)
• Choisissez une méthode de blocage: htaccess, code dans functions.php, extension ou WAF
• Ajoutez la règle de blocage et vérifiez que le point de terminaison renvoie 403 Forbidden
• Si vous utilisez Jetpack, configurez une protection pare-feu ciblée au lieu de désactiver complètement

Qu'est-ce que xmlrpc.php et pourquoi est-il encore dans WordPress

XML-RPC (Remote Procedure Call) est un protocole qui permet à des applications externes de communiquer avec WordPress. Il a été ajouté au cœur dès la version 1.5 et a servi pendant des décennies comme seule API de publication à distance: les applications mobiles WordPress, les clients de bureau comme Windows Live Writer et les services tiers en dépendaient tous.

Avec la sortie de l'API REST WordPress en version 4.7 (2016), le besoin de XML-RPC a largement disparu. L'API REST moderne couvre tout ce que faisait XML-RPC, de manière plus sécurisée, plus rapide et avec une authentification correcte via nonce ou OAuth.

Mais le fichier xmlrpc.php reste à la racine de chaque installation WordPress. La publication à distance via ce fichier est désactivée par défaut, pourtant le point de terminaison accepte les requêtes. Ouvrez simplement yoursite.com/xmlrpc.php dans un navigateur pour le constater: «XML-RPC server accepts POST requests only». Cela signifie que le point de terminaison est actif et prêt à être attaqué.

Pourquoi xmlrpc.php est dangereux: principaux vecteurs d'attaque

Les attaquants utilisent xmlrpc.php pour deux types d'attaques principaux, et les deux peuvent mettre votre site hors service.

Force brute via system.multicall. La méthode system.multicall permet de regrouper des centaines de tentatives d'authentification en UNE SEULE requête HTTP. Au lieu de tester les mots de passe un par un (comme via wp-login.php), un robot envoie un tableau de logins et de mots de passe d'un seul coup. Les extensions standard de limitation de connexion ne détectent pas ces requêtes; pour elles, cela ressemble à «une tentative». Résultat: les attaquants testent des milliers de combinaisons en quelques secondes sans déclencher de blocage.

DDoS par pingback. La fonction pingback permet à un autre site de notifier votre WordPress d'un lien vers celui-ci. Un attaquant envoie une requête pingback falsifiée, en substituant l'adresse IP de la victime comme «source». Votre serveur vérifie consciencieusement le lien et attaque un hôte cible innocent. Multipliez cela sur des milliers d'installations WordPress compromises et vous obtenez une attaque DDoS distribuée où votre site sert de chair à canon.

Les hébergeurs surveillent ce type de trafic sortant et peuvent geler votre compte pour «participation à un DDoS». Pendant ce temps, votre serveur gaspille CPU, mémoire et bande passante à traiter des requêtes indésirables.

Vérification: votre xmlrpc.php répond-il

Avant de bloquer, assurez-vous que le point de terminaison est effectivement ouvert. Ouvrez ceci dans votre navigateur:

1
https://yoursite.com/xmlrpc.php

Si vous voyez la chaîne «XML-RPC server accepts POST requests only», le point de terminaison est actif et les attaquants peuvent lui envoyer des requêtes. Si vous obtenez 403 Forbidden ou 404, la protection fonctionne déjà.

Deuxième méthode: envoyez une requête POST de test via le terminal:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Une réponse avec 200 OK et une structure XML confirme: XML-RPC accepte les requêtes et est prêt à être exploité.

Méthode 1: blocage rapide via.htaccess

La méthode la plus simple et la plus efficace consiste à bloquer l'accès au fichier au niveau du serveur web. La requête est rejetée avant d'atteindre WordPress, ce qui économise les ressources du serveur et fonctionne même si le site est sous charge.

Ajoutez ceci à votre .htaccess racine (celui qui se trouve à côté de wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

La directive Require all denied est la syntaxe Apache 2.4+, en vigueur chez tous les hébergeurs modernes. Après avoir sauvegardé, ouvrez xmlrpc.php dans votre navigateur; vous devriez obtenir 403 Forbidden.

Si votre serveur utilise nginx, ajoutez la règle à la configuration de l'hôte virtuel:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Après avoir modifié la configuration nginx, n'oubliez pas de recharger le serveur: sudo nginx -s reload.

Cette méthode fonctionne si vous n'avez DÉFINITIVEMENT pas besoin de XML-RPC, ni pour Jetpack, ni pour les applications mobiles WordPress, ni pour les intégrations WooCommerce.

Méthode 2: désactivation via functions.php (méthode programmatique)

Si vous préférez résoudre le problème au niveau du code plutôt que par la configuration serveur, voici deux extraits testés pour le functions.php de votre thème actif ou Code Snippets.

Désactivation complète de XML-RPC (WP 3.5+):

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

Une seule ligne, et WordPress cesse de traiter toute requête XML-RPC. Lors de la tentative d'accès à xmlrpc.php, le client reçoit une réponse d'erreur; le fichier lui-même reste sur le serveur mais est fonctionnellement mort.

Nettoyage des en-têtes wp_head des liens RSD et WLW:

Même après avoir désactivé XML-RPC WordPress continue d'insérer deux lignes dans <head> qui révèlent des informations sur votre site:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Les hooks rsd_link et wlwmanifest_link ajoutent les balises <link rel="EditURI"> et <link rel="wlwmanifest"> dans <head>; elles existent exclusivement pour les clients XML-RPC et ne servent à rien en pratique en 2026. Supprimez-les.

⚠️ Important: les modifications du functions.php du thème seront perdues lors d'une mise à jour. Utilisez un thème enfant ou l'extension Code Snippets pour un stockage permanent du code personnalisé.

Méthode 3: extensions de sécurité

Si vous ne voulez pas toucher au code, installez une extension. Trois options testées:

• Wordfence Security. Le pare-feu WordPress le plus populaire. En plus de bloquer XML-RPC, il fournit un scanner de malwares, une protection de connexion et une surveillance du trafic. Dans les paramètres Wordfence → Sécurité de connexion → cochez «Disable XML-RPC authentication».

• Disable XML-RPC-API. Une extension légère qui fait exactement une chose: elle se branche sur le filtre xmlrpc_enabled et désactive le point de terminaison. Aucun réglage supplémentaire; activez et oubliez.

• iThemes Security (Solid Security). Une extension complète avec un module WordPress Tweaks où XML-RPC est désactivé d'une simple case à cocher. Elle ferme également d'autres vecteurs: changement de préfixe de table, désactivation de l'éditeur de fichiers depuis l'administration, protection contre la force brute.

Après avoir activé l'une de ces extensions, vérifiez toujours que xmlrpc.php renvoie une erreur, pas un message d'accueil.

Méthode 4: blocage au niveau du pare-feu (Cloudflare / Sucuri)

Le niveau de protection le plus puissant est un pare-feu applicatif web qui rejette les requêtes malveillantes avant même qu'elles n'atteignent votre hébergement.

WAF Cloudflare. Créez une règle personnalisée: le champ URI Path contient xmlrpc.php → action Block. Les requêtes sont filtrées au niveau du réseau Cloudflare (plus de 330 points de présence dans le monde); votre serveur ne les voit jamais. Le plan Free inclut 5 règles personnalisées, ce qui est suffisant. Bonus: Cloudflare affiche les statistiques des requêtes bloquées et vous pouvez constater l'ampleur de l'attaque de vos propres yeux.

Pare-feu de site web Sucuri. Approche similaire: une règle WAF sur l'URI /xmlrpc.php. Sucuri propose également une surveillance de l'intégrité des fichiers et un nettoyage automatique des malwares.

Une règle de pare-feu fonctionne bien en combinaison avec .htaccess ou la désactivation programmatique: le pare-feu coupe le gros du trafic indésirable, tandis que le blocage local sert de filet de sécurité au cas où le trafic contournerait le WAF.

Que faire si vous utilisez Jetpack

Jetpack d'Automattic utilise XML-RPC pour lier votre site aux serveurs WordPress.com. Si vous désactivez complètement xmlrpc.php, Jetpack cesse de fonctionner: statistiques, abonnements, CDN d'images, le module Articles similaires et la protection anti-force brute de Jetpack sont tous interrompus en même temps.

La solution: ne supprimez pas entièrement XML-RPC, mais autorisez sélectivement les requêtes provenant des serveurs Jetpack:

• Laissez xmlrpc.php accessible (ne bloquez PAS via .htaccess et ne vous branchez PAS sur le filtre xmlrpc_enabled).

• Configurez le WAF Cloudflare ainsi: autorisez les requêtes vers xmlrpc.php UNIQUEMENT depuis les plages IP d'Automattic (la liste est mise à jour dans la documentation Jetpack), bloquez le reste.

• Au minimum, supprimez les en-têtes RSD et WLW en utilisant l'extrait de la méthode 2, afin de ne pas exposer inutilement le point de terminaison dans <head>.

• Installez Wordfence et activez la protection anti-force brute spécifiquement pour xmlrpc.php; elle ne bloque pas les requêtes légitimes de Jetpack mais coupe les tentatives de devinette de mot de passe.

⁉️🤔 Foire aux questions

Puis-je simplement supprimer le fichier xmlrpc.php du serveur?

Vous pouvez, mais c'est une mauvaise pratique. Lors de la prochaine mise à jour de WordPress, le fichier sera restauré et vous serez à nouveau vulnérable. Il est préférable de bloquer l'accès via .htaccess ou de désactiver la fonctionnalité avec un filtre dans le code: l'effet est le même, mais les mises à jour du cœur ne briseront pas votre protection. Si vous avez supprimé le fichier, assurez-vous de retirer rsd_link de wp_head, sinon les visiteurs obtiendront une erreur 404 en suivant le lien EditURI.

La désactivation de XML-RPC cassera-t-elle WooCommerce?

Non. WooCommerce a entièrement migré vers l'API REST WordPress et ne dépend pas de XML-RPC. Votre boutique continuera de fonctionner sans changement. La seule exception est si vous utilisez une ancienne solution personnalisée liée à XML-RPC, mais il n'en reste pratiquement aucune.

Que faire si mon hébergeur bloque déjà xmlrpc.php?

Si l'hébergeur a déjà désactivé XML-RPC au niveau du serveur, vous n'avez rien à faire; le point de terminaison est inaccessible. Vérifiez: ouvrez xmlrpc.php; si vous voyez 403, la protection fonctionne. La seule chose qui vaut la peine d'être ajoutée est la suppression des en-têtes RSD et WLW via functions.php, car l'hébergeur ne les touche pas.

Dois-je désactiver XML-RPC si je suis sur un hébergement WordPress géré?

La plupart des hébergeurs gérés (Kinsta, WP Engine, SiteGround) bloquent ou limitent strictement xmlrpc.php au niveau de la plateforme. Vérifiez si le point de terminaison est ouvert via le navigateur. S'il est bloqué, aucune action supplémentaire n'est requise. S'il est ouvert, ajoutez la règle .htaccess: les hébergeurs gérés ne l'écrasent pas.

Comment savoir si mon site est attaqué via xmlrpc.php en ce moment même?

Trois signes: un pic brutal de charge serveur avec un trafic inchangé, des centaines de requêtes POST identiques vers xmlrpc.php dans les journaux d'accès et des erreurs de limite mémoire/CPU de la part de votre hébergeur. Activez la surveillance (Wordfence → Trafic en direct ou Cloudflare → Événements de sécurité); vous verrez la source et l'ampleur de l'attaque en temps réel.

Vaut-il la peine de désactiver xmlrpc.php en 2026

Réponse courte: oui, si vous n'utilisez pas Jetpack et ne publiez pas d'articles via l'application mobile WordPress.

XML-RPC est un héritage de l'époque WordPress 1.5. L'API REST a depuis longtemps pris sa place, et xmlrpc.php lui-même est devenu une porte ouverte aux attaques par force brute et DDoS. Le fermer prend cinq minutes. Choisissez la méthode adaptée à votre situation:

• Vous ne voulez pas toucher au code: installez Disable XML-RPC-API, deux clics.
• Vous avez accès aux fichiers du serveur: ajoutez une règle au .htaccess, le niveau serveur est plus fiable.
• Vous préférez le code propre: appliquez le filtre xmlrpc_enabled et supprimez les en-têtes avec deux extraits dans functions.php.
• Vous voulez une protection maximale: configurez une règle WAF dans Cloudflare et combinez-la avec un blocage local.

Après le blocage, vérifiez toujours que xmlrpc.php renvoie 403 Forbidden et surveillez les journaux pendant au moins une semaine; vous serez surpris de la quantité de trafic indésirable qui disparaît. Abonnez-vous également aux mises à jour WordPress: l'histoire montre que les anciens protocoles meurent lentement et que de nouvelles vulnérabilités XML-RPC pourraient apparaître même après 2026.