xmlrpc.php : faut-il le désactiver sur WordPress ?

0,11 %. Voilà ce que pèse xmlrpc.php dans les journaux de mon serveur : une requête sur 940, mesurée sur 14 jours, du 16 au 29 septembre 2026. Sur la même période, wp-login.php en a reçu 39 fois plus.

Et pourtant, partout, la consigne est la même : désactivez XML-RPC, cette porte ouverte aux pirates. Le conseil part d’un bon sentiment. Il a un peu vieilli, surtout… et presque personne ne vous dit comment fermer ce fichier pour de bon.

Mon propre site en a fait la démonstration. Le réglage que tout le monde recopie ne ferme pas xmlrpc.php : il en coupe une partie, WordPress continue de répondre, et quatre audits de sécurité de suite ont lu cette réponse de quatre façons différentes.

xmlrpc.php, c’est quoi ?

xmlrpc.php est le fichier de WordPress qui reçoit les appels XML-RPC : des requêtes web (HTTP) de type POST, écrites en XML (un format de texte à balises), par lesquelles un logiciel extérieur demande au site de publier un article, d’envoyer une image ou d’enregistrer un rétrolien. Il est posé à la racine de chaque installation et activé d’office depuis WordPress 3.5.

La spécification du protocole, signée Dave Winer et datée du 15 juin 1999, définit un message XML-RPC comme une requête HTTP POST dont le corps est en XML.

Dans WordPress, il est là depuis très longtemps. La classe qui sert ces appels porte la mention "depuis la 1.5.0", une version annoncée le 17 février 2005. Vous lirez souvent que WordPress l’embarque "depuis 2012" : 2012 est seulement l’année où il a été réactivé par défaut.

Publication distante désactivée en 2008, réactivée par défaut en 2012

En juillet 2008, WordPress 2.6 désactive la publication distante par défaut. Le billet de sortie parle d’une publication à distance désormais "secure (off) by default", avec une option pour la rallumer.

Le 11 décembre 2012, WordPress 3.5 fait le chemin inverse. XML-RPC est activé par défaut et l’option disparaît de l’écran Réglages > Écriture. Le même changement crée un filtre pour ceux qui voudraient encore le couper, xmlrpc_enabled. Retenez ce nom, il va nous occuper un moment…

L’API REST, l’interface plus récente par laquelle un logiciel dialogue avec WordPress, entre dans le cœur en deux temps, avec la 4.4 (décembre 2015) puis la 4.7 (décembre 2016). Elle n’a pas remplacé XML-RPC pour autant. Les deux cohabitent, et les mots de passe d’application arrivés avec la 5.6 (décembre 2020) sont acceptés par l’une comme par l’autre.

Ce que le fichier charge à chaque appel

Ouvrez le fichier, dans sa version 7.1.2 : 106 lignes. Il déclare la requête comme un appel XML-RPC, jette les cookies, puis charge WordPress en entier, extensions comprises.

La main passe ensuite à une classe de plus de 7 000 lignes, qui déclare 77 méthodes : 50 propres à WordPress, les autres héritées des API Blogger, MetaWeblog et Movable Type ou dédiées aux rétroliens et aux tests. Trois méthodes system.* s’y ajoutent, dont une certaine system.multicall.

Et WordPress annonce lui-même l’adresse du fichier, par défaut, avec une balise EditURI dans l’en-tête de vos pages. Les robots n’ont même pas à deviner.

Qui se sert encore de xmlrpc.php aujourd’hui ?

La réponse a bougé en 2026. J’ai donc fait relire, fin septembre, les pages d’aide et les notes de version de chacun. Voici l’état des lieux, source par source.

Qui	A besoin de xmlrpc.php ?	Ce que dit la source
Jetpack	Oui	XML-RPC relie le site à WordPress.com ; bloquer le fichier casse la connexion
Application WordPress pour iOS	Plus obligatoire	Fonctionne sans XML-RPC depuis la 26.7 (mars 2026), avec des fonctions limitées
Application WordPress pour Android	Non documenté	Les notes de version ne disent rien de XML-RPC
Zapier	Non	La page, mise à jour le 1er octobre 2026, demande l’extension Zapier for WordPress, qui passe par l’API REST
IFTTT	Oui	Accès au fichier exigé à la connexion, puis à chaque exécution
MarsEdit	Oui	Ce logiciel de publication parle à WordPress par xmlrpc.php
Rétroliens reçus (pingbacks)	Oui	Ils arrivent par la méthode pingback.ping

L’application mobile hésite, Jetpack non

On vous dira ici que l’application mobile a besoin de XML-RPC, là qu’elle s’en passe. Les deux sont datés. Sur iOS, elle se connecte par mot de passe d’application depuis la 26.6 (février 2026) et tourne sans XML-RPC depuis la 26.7, mais avec des fonctions limitées. En août 2026, la 27.1 réparait encore les catégories sur ces sites.

Jetpack, lui, ne laisse aucun doute (je le présente dans mon tour d’horizon de l’extension Jetpack).

Sa documentation l’écrit noir sur blanc : XML-RPC relie votre site à WordPress.com. Jetpack n’y envoie ni identifiant ni mot de passe (il utilise des jetons), et compte y rester "aussi longtemps que possible". J’ai ce cas sur une boutique WooCommerce cliente dont j’assure la maintenance : j’y reviens plus bas.

Qu’est-ce qui ne passe pas par ce fichier ? Les trackbacks ont le leur, wp-trackback.php. La publication par e-mail du cœur passe par wp-mail.php. Quant aux rétroliens que votre site envoie et aux pings vers les services de mise à jour, ce sont des appels sortants. Fermer xmlrpc.php n’en coupe aucun.

Ce que les attaquants en font, et ce que WordPress a déjà corrigé

On range sous le même mot des attaques qui n’ont rien à voir entre elles. Autant les démêler, parce que la plus citée est aussi la plus périmée.

La force brute, et l’amplification de 2015

xmlrpc.php est une seconde porte de connexion. Chaque méthode protégée vérifie l’identifiant et le mot de passe avec la même fonction que le formulaire, wp_authenticate. Sans formulaire, justement : ni captcha, ni code à six chiffres.

WordPress le reconnaît dans son guide des mots de passe d’application : un appel XML-RPC ne peut pas afficher d’étape interactive. Une extension de double authentification sur WordPress doit donc choisir entre refuser ces appels et les laisser passer.

À l’automne 2015, la force brute change d’échelle. system.multicall regroupe plusieurs appels dans une seule requête, et des attaquants s’en servent pour essayer des centaines de mots de passe d’un coup. Sucuri le décrit le 8 octobre.

La réponse de WordPress tient dans un commit du 23 octobre 2015, livré avec la 4.4 le 8 décembre. Après un premier échec d’authentification dans un appel, toutes les tentatives suivantes du même appel échouent. Ce garde-fou est toujours dans le code de la 7.1.2.

Vous lirez pourtant, y compris dans des pages retouchées en 2026, qu’une requête suffit à tester des centaines d’identifiants. C’était vrai à l’automne 2015, et seulement jusqu’à la 4.4.

Attention toutefois à ne pas en déduire trop. system.multicall existe toujours, et chaque requête permet encore un essai de mot de passe. Le cœur ne compte pas ces essais : sa documentation renvoie la limitation de débit au serveur ou à une extension.

Les rétroliens : votre site sert de relais

L’autre attaque passe par pingback.ping, la méthode des rétroliens. On lui donne l’adresse de la page qui fait le lien et celle de la page visée. WordPress va alors chercher lui-même la première, pour vérifier que le lien existe.

L’attaquant désigne comme "source" le site d’une victime, puis répète la demande auprès de milliers de WordPress, qui téléchargent tous cette page en même temps. Votre site n’est pas la cible. Il sert de relais, à votre insu (on lit souvent l’inverse).

Le 30 avril 2013, le blog d’Imperva décrit une attaque partie d’environ 2 500 sites WordPress, aucun piraté. En mars 2014, Sucuri en compte plus de 162 000 lancés contre un seul site, et prévient que le problème ne sera pas corrigé.

Il l’a été en partie. Depuis WordPress 3.9 (avril 2014), la requête de vérification transporte l’adresse IP de celui qui a demandé le rétrolien : l’attaquant n’est plus caché derrière votre site. En février 2016, Sucuri relevait pourtant encore 26 000 sites lancés contre une seule cible.

Depuis WordPress 7.1, les rétroliens sont coupés d’office dans les environnements déclarés local, development ou staging avec WP_ENVIRONMENT_TYPE. Sans déclaration, WordPress considère le site comme étant en production. En production, ils restent ouverts par défaut sur une installation neuve.

Déprécié ? Non, et pas près de l’être

Alors pourquoi WordPress garde-t-il ce fichier ? Parce que trop de choses en dépendent. Le 2 juillet 2025, sur le blog des développeurs du cœur, Jonathan Desrosiers propose de placer XML-RPC en "mode maintenance" : plus de nouvelles fonctions, seulement des corrections.

XML-RPC est indispensable à de nombreuses applications et services externes qui interagissent avec WordPress, il ne peut donc pas être déprécié.

Jonathan Desrosiers, make.wordpress.org/core, 2 juillet 2025 (traduit de l’anglais)

Il a clos la discussion le 30 juillet 2025, en annonçant des ajustements. Depuis, rien d’officiel : la page du composant XML-RPC ne parle pas de mode maintenance. Mais le fichier est entretenu : les 23 et 25 septembre 2026, deux durcissements de XML-RPC sont encore entrés dans la version en développement.

Ce que disent mes journaux : 14 jours de requêtes

Restait à mesurer ce que ce fichier pèse pour de vrai. Le 30 septembre 2026, j’ai fait compter les requêtes des 14 jours précédents dans les journaux du serveur qui héberge le WordPress de ce site. Je ne vous donne que des parts et des rapports.

Ce que la mesure donne (16 au 29 septembre 2026)	Valeur
Part de xmlrpc.php dans les requêtes reçues	0,11 %, soit une sur 940
wp-login.php, sur la même période	39 fois plus (4,2 % des requêtes)
Fichiers .env	92 fois plus (9,8 % des requêtes)
Requêtes POST, parmi celles qui visent xmlrpc.php	87 %
Requêtes qui se présentent comme un navigateur	100 %, dont 99 % comme Chrome
Requêtes qui s’annoncent comme Jetpack, comme l’application mobile ou comme un logiciel de publication	0 %
Requêtes écrites //xmlrpc.php, avec une double barre	29 %

Des robots qui passent, sans insister

Qui frappe à cette porte ? Des robots, selon toute apparence. Toutes les requêtes se présentent comme un navigateur, Chrome dans 99 % des cas, parfois dans une vieille version (78, 89 ou 95). Aucune ne s’annonce comme Jetpack, comme l’application mobile ou comme un logiciel de publication. Et pour cause : le WordPress de ce site ne s’en sert pas.

Ils ne s’acharnent pas. Deux requêtes par adresse en moyenne, près de deux adresses sur trois qui n’en font qu’une, et pas une seule rafale sur toute la période. Et cette double barre oblique dans près d’une requête sur trois… Personne ne tape ça à la main.

La page de connexion raconte une autre histoire. wp-login.php attire à peu près deux fois plus d’adresses, pour bien plus de requêtes par adresse : là, on insiste.

Sur un serveur où tournent des sites reliés à Jetpack, le tableau serait tout autre, en effet : une partie des requêtes viendrait de WordPress.com, et celles-là sont légitimes.

Chez moi, donc, xmlrpc.php est une cible marginale. Le fermer reste justifié, mais je ne vais pas vous le présenter comme la porte la plus frappée de WordPress.

Pourquoi "désactiver XML-RPC" ne ferme pas le fichier

Sur le WordPress de ce site, XML-RPC était censé être désactivé : je l’ai même écrit dans deux articles. Un mu-plugin, ces extensions que WordPress charge d’office, y pose ces lignes. Le commentaire laissé dans le code annonce la couleur.

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

Le 3 juin 2026, un audit de sécurité interroge le fichier. Il reçoit "XML-RPC server accepts POST requests only", en conclut que XML-RPC est actif et recommande de le désactiver par un filtre… celui qui était déjà en place.

Une semaine plus tard, deuxième audit, même réponse, lecture inverse : le filtre est actif, rien à signaler. Le 3 juillet, troisième passage. L’alerte tombe (le fichier répond), puis elle est levée. Interrogé sur ses méthodes, le serveur n’en avoue plus que trois, les system.*.

Le lendemain, quatrième audit. Il note "xmlrpc.php actif" et recommande, cette fois, autre chose qu’un filtre : une règle Nginx. Elle est posée le jour même. Dans mon journal de bord, la ligne du 4 juillet 2026 est brève : "xmlrpc 403 (était 405)".

Aucun de ces audits ne se trompait sur ce qu’il voyait. Le fichier répondait, parce que ce filtre n’a jamais servi à le fermer.

Ce que dit la documentation du filtre, sans détour

Contrairement à ce que son nom laisse penser, ce filtre ne contrôle pas si XML-RPC est entièrement activé : il contrôle seulement si les méthodes XML-RPC qui exigent une authentification […] sont activées.

Documentation de WordPress, filtre xmlrpc_enabled (traduit de l’anglais)

La suite du texte ajoute que le filtre ne contrôle pas non plus les rétroliens. La précision date de mars 2016. Son auteur y rappelle que ce filtre remplaçait une case à cocher qui, déjà, ne coupait que les méthodes de publication.

En pratique, avec ce filtre à faux, les méthodes protégées par mot de passe renvoient l’erreur "XML-RPC services are disabled on this site". Dix autres répondent toujours, dont pingback.ping, system.multicall et system.listMethods. Et à chaque requête, PHP démarre et WordPress se charge en entier avant de refuser.

Mon second filtre, celui qui vide la liste des méthodes, retire bien celles du cœur, rétroliens compris. Il ne peut rien contre les trois system.*, que WordPress réinscrit après lui. C’est exactement ce que le troisième audit avait vu.

L’extension la plus installée tient en une ligne

Prenez, par exemple, l’extension la plus installée du répertoire de WordPress.org pour ce seul travail.

Son code actif tient en une ligne, celle du filtre :

add_filter( 'xmlrpc_enabled', '__return_false' );

Sa fiche ne s’en cache pas, elle annonce utiliser le filtre intégré de WordPress. Mais l’installer ne ferme ni les rétroliens, ni system.multicall, ni le fichier. Vous obtenez moins que ce que ce site avait avant le 4 juillet : le second filtre, au moins, y retirait les rétroliens.

Le test dans le navigateur qui trompe tout le monde

Vous connaissez sans doute ce test. Ouvrez votre-site.fr/xmlrpc.php dans le navigateur : si la page affiche "XML-RPC server accepts POST requests only.", XML-RPC serait actif.

Le message est exact. WordPress l’envoie à toute requête qui n’est pas un POST, avec un code 405, quelle que soit la valeur du filtre. Filtre posé ou non, extension installée ou non, la page affiche la même phrase. Elle prouve une seule chose : PHP a répondu.

Les codes HTTP réservent un autre piège. Quand XML-RPC refuse un mot de passe, l’erreur voyage dans le XML et la réponse HTTP reste un 200. Un journal plein de "200" sur xmlrpc.php ne dit donc pas que quelqu’un est entré. Avec le filtre, le refus sort en 405.

Mon outil Score WordPress, qui teste xmlrpc.php parmi ses contrôles de sécurité, lit ces codes à votre place : il classe le fichier "Accessible" dès qu’il répond 200 ou 405. Un site protégé par le seul filtre y reste donc en rouge.

Comment bloquer xmlrpc.php au niveau du serveur ?

Pour fermer réellement xmlrpc.php, il faut que le serveur web refuse la requête avant de lancer PHP : une règle location = /xmlrpc.php avec deny all sous Nginx, un bloc Files avec Require all denied sous Apache 2.4. Aucun code WordPress ne s’exécute, aucune méthode ne répond, et la règle survit aux mises à jour.

La documentation de WordPress sur la force brute va dans ce sens : les extensions s’exécutent dans PHP, mieux vaut agir au niveau du serveur quand c’est possible.

Ne supprimez pas le fichier pour autant. Il appartient au cœur, et la documentation prévient qu’une mise à jour touche tous les fichiers de l’installation : il reviendrait. Voici ce que chaque méthode ferme vraiment.

Méthode	Méthodes avec mot de passe	Rétroliens et system.multicall	WordPress est chargé ?	Réponse à un GET
Filtre xmlrpc_enabled à faux, ou l’extension Disable XML-RPC	Refusées	Répondent	Oui	405
Filtre xmlrpc_methods vidé	Retirées	Rétroliens retirés, system.* répondent	Oui	405
Extension qui refuse en PHP (Login Armor, réglage XML-RPC)	Refusées	Refusés	Oui, jusqu’au crochet init	403
Règle du serveur (Nginx deny all, Apache Require all denied)	Refusées	Refusés	Non	Refus (403 constaté sous Nginx)
Nginx return 444	Refusées	Refusés	Non	Connexion fermée, sans réponse

Sous Nginx

Voilà la règle posée sur mon serveur, dans le bloc server du site :

location = /xmlrpc.php {
    deny all;
}

Le signe = compte. Il demande une correspondance exacte, et la documentation de Nginx est nette : si elle est trouvée, la recherche s’arrête. La règle passe donc avant le bloc qui exécute les fichiers PHP, où qu’elle soit écrite.

Si WordPress est installé dans un sous-dossier, adaptez le chemin (location = /blog/xmlrpc.php).

Ce n’est pas vrai de toutes les règles, et mon serveur en a fait les frais ailleurs. Celles qui s’écrivent avec une expression régulière (~) sont testées dans l’ordre du fichier, et la première qui correspond gagne. Le 2 septembre 2026, les journaux l’ont montré : une interdiction d’exécuter du PHP dans les téléversements, écrite après le bloc PHP, n’avait jamais rien bloqué.

Faut-il répondre 403, ou ne rien répondre du tout ? deny all renvoie un refus, 403 sur mon serveur. Avec return 444;, Nginx ferme la connexion sans envoyer d’en-tête de réponse. Les deux ferment la porte.

Le conseil qui circule : ajouter access_log off. Ma règle ne le fait pas. Sans journal, pas de mesure : celle de cet article n’existerait pas.

Sous Apache 2.4

Sous Apache, la règle se pose dans le .htaccess à la racine du site, au-dessus de la ligne # BEGIN WordPress (WordPress réécrit ce qui se trouve entre ses deux balises) :

<Files "xmlrpc.php">
    Require all denied
</Files>

L’ancienne écriture traîne encore partout, avec Order Allow,Deny puis Deny from all. C’est la syntaxe d’Apache 2.2, une version en fin de vie dont la dernière mouture date de juillet 2017. Elle ne fonctionne en 2.4 que grâce à un module de compatibilité, lui-même déprécié.

La documentation d’Apache déconseille aussi de mélanger les deux écritures. Les autres règles utiles, toutes écrites en syntaxe 2.4, sont dans mon guide des règles .htaccess pour WordPress.

À noter : le .htaccess est relu à chaque requête. Si vous administrez le serveur, écrivez plutôt la règle dans sa configuration principale. Et si l’ajout provoque une erreur 500, retirez le bloc : le site revient aussitôt. Relisez ensuite votre copie, une balise mal fermée suffit. Si elle est exacte, votre hébergeur n’autorise sans doute pas cette directive, et son support vous le confirmera.

Vérifier que c’est fermé

Une règle qu’on n’a pas vérifiée ne protège rien. Ça se contrôle avec curl, depuis votre poste :

# 1. Ce que reçoit un navigateur (requête GET)
curl -sS -o /dev/null -w "%{http_code}\n" https://votre-site.fr/xmlrpc.php

# 2. Ce que reçoit un robot (requête POST, liste des méthodes)
curl -sS -o /dev/null -w "%{http_code}\n" \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' \
  https://votre-site.fr/xmlrpc.php

# 3. Le même contrôle en HTTP simple
curl -sS -o /dev/null -w "%{http_code}\n" http://votre-site.fr/xmlrpc.php

# 4. La variante avec un segment après le nom du fichier
curl -sS -o /dev/null -w "%{http_code}\n" https://votre-site.fr/xmlrpc.php/test

Voici comment lire les codes :

• 405 au GET et 200 au POST : le fichier répond, avec ou sans filtre ;
• 403 aux deux : la requête est refusée, par le serveur ou par une extension qui répond en PHP ;
• 404 : le fichier est absent, ou une règle le fait passer pour tel ;
• 301 ou 308 : l’adresse est redirigée (le site public que vous lisez renvoie ainsi vers sa page d’accueil) ;
• 000 : aucune réponse HTTP reçue. Cela peut venir d’un return 444, mais aussi d’une erreur DNS, TLS ou d’un délai dépassé. Lisez le message d’erreur avant de conclure.

Ne sautez pas la troisième commande. Si l’adresse en http:// ne renvoie pas vers le HTTPS, la règle doit exister dans les deux configurations.

La quatrième teste une variante de l’adresse. Selon la configuration PHP du serveur, elle peut échapper à une correspondance exacte : si elle ne répond pas 403 ou 404, la règle est à élargir.

Que fait déjà votre hébergeur ?

Avant d’écrire la moindre règle, regardez ce que votre hébergeur fait déjà. Certains ferment xmlrpc.php d’office, d’autres vous laissent la main, d’autres n’en disent rien.

Hébergeur	Ce qu’il documente	Page datée du
Kinsta	Tout accès à xmlrpc.php est coupé par défaut	18 septembre 2026
WP Engine	Bloqué par défaut sur les environnements créés après avril 2022, avec un interrupteur	2 mars 2026
HaiSoft	Bloqué par défaut sur ses serveurs mutualisés et ses nouveaux serveurs VM et dédiés ; là où fail2ban est présent, les adresses qui insistent sont bannies	23 septembre 2020
o2switch	Règle de blocage "recommandée" dans l’outil Tiger Protect. La page ne dit pas si elle est active par défaut	6 juin 2026
OVHcloud (mutualisé)	Pare-feu applicatif ModSecurity à activer soi-même ; le guide ne mentionne pas xmlrpc.php	22 août 2025
WordPress VIP	Pas de blocage par défaut : au-delà de 10 requêtes en 30 secondes, l’adresse est bloquée une heure ; sur les nouveaux environnements, seuls les mots de passe d’application sont acceptés, et une option ferme XML-RPC entièrement	26 février 2026

Un blocage par défaut est une bonne nouvelle… jusqu’au jour où vous installez Jetpack. Et une règle "recommandée" n’est pas forcément active : ouvrez votre panneau d’hébergement et vérifiez.

Sans accès au serveur, l’extension de sécurité

Ni accès au serveur, ni règle chez l’hébergeur ? Il reste les extensions de sécurité.

Wordfence range dans ses réglages de connexion une option "Disable XML-RPC authentication". Le libellé est honnête : il parle d’authentification, et l’option s’appuie sur le filtre xmlrpc_enabled. Le reste est dans mon guide complet de Wordfence.

Ce que ma règle ne protégeait pas

En préparant cet article, le 30 septembre 2026, j’ai fait relever les codes de réponse dans mes journaux. 57 % des requêtes vers xmlrpc.php ont reçu un code 200, et un tiers seulement un 403, le code du refus. Pour un fichier censé être bloqué, c’est beaucoup.

Le serveur n’héberge pas que ce site. Il porte aussi deux WordPress de test, et chacun a son propre fichier de configuration Nginx. Ma règle du 4 juillet vit dans celui du site principal. Les autres ne l’avaient pas.

Une requête sur chaque site a levé le doute, ce 30 septembre. Le principal renvoyait le 403 de Nginx. Un WordPress de test refusait lui aussi, mais plus tard, par PHP. L’autre répondait 405 et "XML-RPC server accepts POST requests only". Ouvert, donc. Tout indique que les robots l’avaient trouvé…

Mon journal ne garde ni le site demandé ni le contenu des réponses. Je ne peux donc pas vous dire ce que ces requêtes ont obtenu, ni même affirmer que toutes visaient ce site de test. Je sais seulement qu’elles ont reçu un 200, sur un fichier censé renvoyer un 403.

La règle est posée depuis le même jour sur le site de test resté ouvert. Contrôle refait : 403 sur les trois. La relecture des deux fichiers a aussi montré le défaut d’ordre décrit plus haut : l’interdiction du PHP dans les dossiers de médias y venait après le bloc PHP, donc sans effet. Elle est remontée.

Une règle écrite dans le fichier d’un site ne protège que ce site. Sur un serveur qui porte plusieurs WordPress, elle se recopie dans chaque configuration, ou s’écrit une fois dans un fichier commun que toutes incluent. Ces deux sites de test demandaient pourtant aux moteurs de recherche de ne pas les indexer.

Et si vous devez le garder ouvert ?

Jetpack, l’application mobile, IFTTT… Si l’un d’eux tourne chez vous, fermer xmlrpc.php casse quelque chose. La documentation de WordPress donne alors la consigne : le restreindre par des règles de pare-feu et limiter fortement le débit.

N’ouvrir qu’aux adresses de Jetpack

Jetpack publie les plages d’adresses depuis lesquelles WordPress.com contacte votre site. Sous Apache, le refus devient une liste blanche :

<Files "xmlrpc.php">
    Require ip 122.248.245.244/32 54.217.201.243/32 54.232.116.4/32
    Require ip 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20
    Require ip 195.234.108.0/22 192.0.64.0/18
</Files>

Sous Nginx, les mêmes plages s’écrivent en lignes allow, suivies d’un deny all, dans un bloc location = /xmlrpc.php qui reprend aussi les directives PHP de votre configuration (comme dans l’exemple de limitation de débit, plus bas).

Un mot de passe d’application à la place du vrai

Depuis WordPress 5.6, vous pouvez créer un mot de passe d’application par service. Il s’utilise avec XML-RPC à la place du vrai, ne sert pas à ouvrir une session dans le tableau de bord et se révoque sans toucher au compte.

Toutefois, le vrai mot de passe reste accepté par XML-RPC. Un ticket ouvert propose d’imposer les mots de passe d’application pour ces appels.

Limiter le débit

La documentation de WordPress donne un exemple pour Nginx, que je reprends ici : dix requêtes par minute et par adresse, avec une tolérance de vingt. La première ligne se place dans le bloc http, le reste dans le bloc server du site.

limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m;

server {
    location = /xmlrpc.php {
        limit_req zone=logins burst=20 nodelay;
        include fastcgi_params;
        # puis les directives PHP de votre configuration (fastcgi_pass...)
    }
}

Au-delà du seuil, Nginx répond par une erreur (503 par défaut). Ne collez pas ce bloc à l’aveugle : il remplace votre bloc PHP pour ce fichier, et doit donc en reprendre les directives.

Garder XML-RPC, couper les rétroliens

Vous gardez XML-RPC pour Jetpack, mais vous n’avez que faire des rétroliens. Retirez seulement leur méthode, avec le filtre xmlrpc_methods, dans un fichier posé dans wp-content/mu-plugins/. Le cœur fait exactement cela depuis la 7.1, dans les environnements déclarés hors production.

<?php
/**
 * Plugin Name: Retirer les rétroliens XML-RPC
 */
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Le cas d’une boutique cliente sous Jetpack

Sur la boutique WooCommerce dont je parlais, XML-RPC doit rester ouvert : Jetpack y assure les sauvegardes. Au printemps 2026, une attaque par force brute sur xmlrpc.php a saturé PHP en quelques minutes, et la sauvegarde en cours a échoué.

Fermer le fichier aurait réglé l’attaque et cassé Jetpack. La parade a donc été une liste blanche des adresses de Jetpack dans le .htaccess, doublée d’un mu-plugin qui retire les méthodes dont les attaquants abusaient.

L’été suivant, le problème est venu d’ailleurs. La protection de l’hébergeur soumettait xmlrpc.php à une vérification de navigateur. Jetpack est un robot, il ne peut pas la passer. Il a relancé ses appels en rafale, et le site en est devenu indisponible un court moment. La réponse a été une limite de débit par adresse sur ce fichier.

Garder XML-RPC pour une extension revient à l’ajouter à votre surface d’attaque. Surveillez ses failles : mon outil Veille Sécurité, gratuit pour les abonnés, compare chaque jour vos extensions à la base WPVulnerability.net. Et si vous préférez déléguer, mes forfaits de maintenance démarrent à 590 € HT par mois.

Masquer la page de connexion suffit-il ?

Non. Masquer ou déplacer la page de connexion ne protège pas xmlrpc.php, qui vérifie les identifiants sans passer par wp-login.php. Si les méthodes d’authentification XML-RPC restent autorisées, un robot peut encore y essayer des mots de passe, une requête après l’autre. La page masquée réduit le bruit, elle ne ferme pas cette seconde porte.

Vous lirez parfois que déplacer la page de connexion "ne sert à rien" tant que ce fichier reste ouvert, parce qu’il avalerait des dizaines de tentatives par requête. J’ai fait vérifier l’affirmation.

Le fond est juste : les deux portes sont indépendantes. La conclusion va trop loin. Sur mon serveur, wp-login.php reçoit 39 fois plus de requêtes que xmlrpc.php : la page de connexion reste de loin la plus sollicitée. Mon journal compte des requêtes, pas des mots de passe essayés. Quant aux dizaines de tentatives par requête, l’argument est périmé depuis WordPress 4.4.

WPS Hide Login ne touche pas à ce fichier

Cette extension, dont je suis l’un des créateurs, ne touche pas à xmlrpc.php. Vérification faite dans le code de sa version 1.9.19 : aucune occurrence de "xmlrpc", de "multicall" ni de "pingback". Elle masque wp-login.php et wp-admin. Rien d’autre.

Je l’ai présentée dans mon guide pour changer l’adresse de connexion de WordPress, et sa propre fiche renvoie vers une extension sœur pour limiter les tentatives de connexion par force brute. Sur le serveur de ce site, deux mécanismes distincts ferment les deux portes : WPS Hide Login pour la page de connexion, Nginx pour xmlrpc.php.

Login Armor le ferme, en PHP

Login Armor, maintenant. C’est mon extension : je l’ai créée et je la développe. Prenez ce qui suit comme la parole d’un auteur, vérifiable dans le code.

Son réglage "Disable XML-RPC" répond 403, avec le message "XML-RPC is disabled.", avant que WordPress ne traite l’appel. Constaté sur un site local en 7.1.2, en GET comme en POST. Il n’est pas actif à l’installation : il fait partie des sept réglages recommandés, que l’on applique d’un bouton.

Un réglage séparé retire les seuls rétroliens. Et si votre page de connexion est masquée pendant que des attaques arrivent par xmlrpc.php, le tableau de bord vous le dit : "Hide Login is on, but XML-RPC is still open."

Sa limite est celle de toute extension, déjà dite : le refus vient de PHP. Avec un accès au serveur, la règle Nginx ou Apache reste la meilleure fermeture. Le détail est dans ma présentation de Login Armor et de ses protections.

Alors, faut-il désactiver xmlrpc.php ?

Je ne coupe pas xmlrpc.php d’office. Je commence par regarder qui s’en sert. Si une extension ou une fonction du site en a besoin, je le garde et je le verrouille au maximum. Si rien ne s’en sert, je le ferme : c’est une porte d’entrée de moins à surveiller. Tout dépend du projet.

Regarder qui s’en sert, en une commande

Vos journaux donnent un premier élément de réponse. Cette commande lit tous les journaux d’accès conservés, archives compressées comprises, et liste les agents utilisateurs (le nom sous lequel chaque logiciel se présente) qui appellent le fichier, du plus fréquent au plus rare. Adaptez le chemin du journal :

zgrep -hE '"[A-Z]+ [^ "]*/xmlrpc\.php[/? ]' /var/log/nginx/access.log* \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr

Lisez la liste jusqu’en bas : un service qui n’appelle le fichier qu’une fois par semaine s’y trouve tout à la fin. Si un nom connu y figure (Jetpack, par exemple), c’est un indice à recouper avec les services connectés. Ce nom peut être imité. Une liste qui ne montre que des navigateurs, comme chez moi, reste un indice : chaque logiciel choisit le nom sous lequel il se présente.

Avant de fermer, le tour du site

Avant de fermer, faites donc aussi le tour du site : les extensions actives, les services connectés, l’application mobile d’un collègue. Vos journaux ne couvrent que la période conservée (14 jours sur mon serveur), et une tâche mensuelle peut leur échapper. Puis fermez, et regardez ce qui cesse de fonctionner les jours suivants.

Votre situation	Ce que la méthode donne
Rien ne s’en sert, et vous administrez le serveur	Le fermer par une règle Nginx ou Apache, puis vérifier avec curl
Rien ne s’en sert, sans accès au serveur	La règle .htaccess, ou celle de votre hébergeur ; à défaut, une extension qui répond 403
Jetpack	Le garder, n’ouvrir qu’aux adresses de Jetpack, limiter le débit
Application mobile	Tester l’application sans XML-RPC ; s’il manque une fonction, le garder et limiter le débit
IFTTT, MarsEdit	Le garder, avec un mot de passe d’application par service et une limite de débit
XML-RPC utile, rétroliens inutiles	Retirer la seule méthode pingback.ping
Plusieurs WordPress sur le même serveur	Écrire la règle une fois, dans un fichier commun à tous les sites

Le reste de l’hygiène (comptes, mots de passe, sauvegardes) est dans ma checklist pour sécuriser WordPress étape par étape.

Désactiver xmlrpc.php n’est pas une décision de principe. Regardez qui s’en sert, puis tranchez sans demi-mesure : fermé pour de bon au niveau du serveur si personne n’en a besoin, gardé et verrouillé sinon. Le seul mauvais choix est l’entre-deux que ce site a connu jusqu’au 4 juillet 2026, un fichier "désactivé" qui répond à tout le monde.

Questions fréquentes

Peut-on supprimer le fichier xmlrpc.php ?

Mieux vaut l’éviter. xmlrpc.php fait partie des fichiers livrés avec WordPress, et chaque mise à jour de WordPress les réinstalle : il reviendrait. Une règle posée au niveau du serveur survit aux mises à jour.

Quelle différence entre XML-RPC et l’API REST de WordPress ?

Ce sont deux interfaces distinctes. XML-RPC, présent au moins depuis WordPress 1.5, passe par xmlrpc.php. L’API REST est entrée dans le cœur avec les versions 4.4 et 4.7. Elle ne l’a pas remplacé partout : Jetpack et IFTTT en dépendent encore, alors que Zapier est passé par l’API REST avec son extension.

Jetpack fonctionne-t-il sans xmlrpc.php ?

Non. Sa documentation indique que bloquer le fichier casse la connexion avec WordPress.com. Gardez alors xmlrpc.php ouvert aux seules plages d’adresses que Jetpack publie, et ajoutez une limite de débit.

Comment savoir si xmlrpc.php est actif sur mon site ?

Pas avec le navigateur : son message s’affiche que le filtre soit posé ou non. Lancez une requête avec curl et lisez le code de réponse. 405 au GET ou 200 au POST, le fichier répond. 403, la requête est refusée.

Sources

Sources vérifiées le 7 octobre 2026 ; citations traduites de l’anglais.

• Code de WordPress 7.1.2 : fichier d’entrée, classe wp_xmlrpc_server, classe IXR_Server et fonctions de rétroliens
• Commits du cœur : activation par défaut (2012), adresse transmise dans les rétroliens (2014), rétroliens coupés hors production (2026), durcissements des 23 et 25 septembre 2026
• Documentation de WordPress : filtre xmlrpc_enabled, filtre xmlrpc_methods, mots de passe d’application, versions 3.9, 4.4, 4.7 et 5.6, annonce de la 1.5
• Avenir de XML-RPC : proposition de mode maintenance et page du composant XML-RPC
• Serveurs : Nginx (allow et deny, return 444, limit_req) et Apache (Require, Require ip, AllowOverride, fichiers .htaccess, fin de vie de la 2.2)
• Jetpack : problèmes de connexion et listes d’adresses en texte brut et en JSON
• Extensions lues dans leur code : Disable XML-RPC 1.0.1, WPS Hide Login 1.9.19, Login Armor 2.7.10 et Wordfence 9.0.2 ; chiffres des fiches relevés par l’API de WordPress.org
• Mesure des journaux : journaux d’accès Nginx de mon serveur, du 16 au 29 septembre 2026, comptés le 30 septembre 2026

Article original sur WPFormation