Faut-il désactiver xmlrpc.php sur WordPress ?
Dernière vérification : 30 octobre 2026
Dans la plupart des cas, oui, sauf si vous dépendez réellement de l'application mobile WordPress ou d'un outil de publication à distance. XML-RPC est activé par défaut sur toute installation WordPress depuis la version 3.5, sans option native pour le désactiver depuis le tableau de bord (source : developer.wordpress.org). Deux risques concrets sont documentés par les éditeurs de sécurité spécialisés : la méthode pingback.ping peut transformer un site en relais d'une attaque par déni de service contre un tiers, et la méthode system.multicall permet de regrouper des centaines de tentatives de mot de passe dans une seule requête, contournant les protections anti-brute-force limitées à wp-login.php (source : Sucuri).
Votre site WordPress est-il à jour et correctement protégé ? Vérifiez-le en 30 secondes.
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Pourquoi xmlrpc.php existe encore
L'API XML-RPC de WordPress reprend les anciennes API Blogger, MovableType et metaWeblog (source : developer.wordpress.org). Avant l'arrivée de l'API REST, c'était le seul moyen pour une application externe — client de publication de bureau, application mobile — de communiquer avec un site WordPress sans passer par le tableau de bord. Elle gère aussi les pingbacks, le mécanisme par lequel un site informe un autre qu'il l'a lié.
Les deux risques concrets, documentés par les éditeurs de sécurité
| Méthode XML-RPC | Usage détourné | Effet |
|---|---|---|
| pingback.ping | Un attaquant demande à de nombreux sites WordPress d'envoyer une requête pingback vers une même adresse cible | Relais dans une attaque par déni de service distribué (DDoS) contre un site tiers, sans que le propriétaire du site relais s'en rende forcément compte (source : Sucuri) |
| system.multicall | Regroupement de centaines de tentatives de connexion (identifiant + mot de passe) dans une seule requête HTTP | Contournement des protections anti-brute-force généralement limitées au formulaire de connexion wp-login.php (source : Sucuri) |
La fausse bonne solution : le filtre xmlrpc_enabled
Beaucoup de tutoriels recommandent d'ajouter add_filter('xmlrpc_enabled', '__return_false') dans functions.php. C'est un vrai filtre officiel de WordPress, documenté par developer.wordpress.org, mais sa portée est plus limitée qu'il n'y paraît : il désactive uniquement les méthodes XML-RPC qui nécessitent une authentification. Les pingbacks et certaines méthodes non authentifiées, dont system.multicall, restent accessibles malgré ce réglage.
Vérifiez votre installation WordPress
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Désactiver xmlrpc.php complètement
- Si vous n'utilisez ni application mobile WordPress, ni outil de publication à distance, ni pingback/trackback entre blogs : bloquez l'accès au fichier xmlrpc.php au niveau du serveur web (règle de configuration Apache ou nginx), ou via une extension de sécurité dédiée au durcissement WordPress.
- Si vous avez besoin de garder certaines fonctions actives : limitez XML-RPC aux seules méthodes réellement utilisées plutôt que de tout bloquer — certaines extensions de sécurité permettent cette granularité.
- Dans tous les cas, vérifiez après coup que la fonctionnalité réellement utilisée (application mobile, service tiers) fonctionne toujours.
Ce que ScanMonSite vérifie à la place
Notre scanner ne teste pas xmlrpc.php : ce point n'entre pas dans son périmètre actuel. Il détecte en revanche la version exacte du cœur WordPress et des plugins installés, pour identifier les failles connues qui, elles, sont directement exploitables — un risque généralement plus élevé que xmlrpc.php lui-même.
Sources
Questions fréquentes
xmlrpc.php est-il activé par défaut sur WordPress ?
Oui. L'API XML-RPC est activée par défaut depuis WordPress 3.5 — l'option permettant de la désactiver depuis le tableau de bord a même été retirée à cette occasion (source : developer.wordpress.org).
Le filtre xmlrpc_enabled désactive-t-il tout XML-RPC ?
Non. Ce filtre officiel, documenté par developer.wordpress.org, ne contrôle que les méthodes XML-RPC nécessitant une authentification (comme la publication à distance) ; les pingbacks et certaines méthodes non authentifiées, dont system.multicall, restent actifs malgré ce réglage.
Qu'est-ce que la méthode system.multicall et pourquoi est-elle risquée ?
Elle permet de regrouper plusieurs appels XML-RPC dans une seule requête HTTP. Un attaquant peut ainsi tester des centaines de combinaisons identifiant/mot de passe en une seule requête, contournant les protections anti-brute-force généralement limitées à wp-login.php (source : Sucuri).
Qu'est-ce que le risque lié à pingback.ping ?
Cette méthode permet à un site d'informer un autre qu'il l'a lié. Détournée, elle permet à un attaquant de faire envoyer, par de nombreux sites WordPress ayant les pingbacks activés, du trafic vers une cible tierce — un relais dans une attaque par déni de service distribué (source : Sucuri).
Désactiver xmlrpc.php casse-t-il des fonctionnalités ?
Cela peut couper l'application mobile officielle WordPress, certains outils de publication à distance et le système de pingback/trackback entre blogs, s'ils sont réellement utilisés sur votre site.
ScanMonSite teste-t-il si xmlrpc.php est désactivé sur mon site ?
Non. Aucun module de notre scanner n'interroge xmlrpc.php : ce point n'est pas couvert par notre analyse automatique actuelle.
Une extension de sécurité suffit-elle à neutraliser le risque ?
C'est la solution la plus simple sur un site existant : elle bloque généralement l'accès au fichier ou aux méthodes sensibles sans intervention sur le code. Une règle de blocage au niveau du serveur web (configuration Apache ou nginx) offre la même protection, de façon plus durable.
Pour aller plus loin
Vérifiez la sécurité de votre site WordPress
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Votre site est déjà touché ? Demandez un devis de réparation.