xmlrpc.php et multicall : encore ouvert après « durcissement »
Un plugin « sécurité » affirme que xmlrpc.php est fermé. Un appel simple montre que non. Après incident, vérifiez vraiment. Si vous n’avez pas d’app mobile WordPress ni de Jetpack utile, fermez-le au serveur — pas seulement dans une case.
Un plugin « sécurité » dit que c'est fermé, un curl montre que non. Vérifiez réellement. Utile après incident si vous n'avez pas d'app mobile WordPress.
À quoi xmlrpc sert encore
xmlrpc.php est une porte d’API ancienne : publication à distance, certaines apps, Jetpack, des crons d’outils. Elle permet aussi des tentatives de login en masse et des enchaînements d’appels (multicall) que les bots aiment. Ce n’est pas un virus. C’est une surface. Après un incident, on décide si vous en avez besoin, puis on mesure si elle est réellement fermée.
Les dossiers « on a durci » échouent ici : case cochée dans iThemes / Wordfence / un mu-plugin, mais le fichier répond encore 200 avec un corps XML. Le bot n’a pas lu votre tableau de bord.
Nous ne publions pas de recettes de brute force. Nous publions comment constater que l’endpoint est vivant, et comment le couper côté serveur sur votre machine.
« Fermé » dans l’extension, ouvert sur le fil
Un plugin qui « bloque xmlrpc » via un filtre PHP ne s’exécute pas si PHP n’est pas atteint (cache), ou s’il y a un second WordPress, ou si la règle ne s’applique qu’à GET. Un attaquant ou un moniteur envoie un POST. Testez en POST, pas en ouvrant l’URL dans Chrome (un GET peut afficher un message anodin). Notez le code et un bout de corps : 403 serveur vs message WordPress « XML-RPC disabled » vs liste de méthodes. Les trois ne se valent pas.
Un CDN qui cache une ancienne 200. Un HTTP où seul le HTTPS est filtré. Un sous-domaine old. où le plugin n’est pas installé.
La case « désactiver xmlrpc » de WordPress n’existe pas nativement comme un interrupteur unique. D’où les plugins, d’où les mensonges de statut.
Vérifier sans bricoler une attaque
Depuis votre machine, un POST vers https://votre-site/xmlrpc.php avec un corps XML minimal de type « system.listMethods » (documentation publique WordPress) : si vous recevez une liste de méthodes, l’endpoint parle. Si vous recevez 403/404/410 du serveur, il est coupé avant PHP. Si vous recevez une faute WordPress « disabled », le filtre PHP tient — moins solide qu’une règle serveur, souvent suffisant pour une vitrine.
Ne lancez pas de multicall, ne testez pas de mots de passe. Vous constatez l’ouverture, vous ne « pénétrez » pas.
Search Console et les logs : des milliers de POST xmlrpc sont un indice de bots, pas à eux seuls d’une réussite. Croisez avec les admins créés et les fichiers.
- POST, pas seulement GET dans le navigateur.
- www et apex, http et https.
- old. et shop. si ils existent.
Où le fermer pour que ça tienne
Règle nginx/Apache ou panel (o2switch « bloquer xmlrpc ») : 403 ou 404 sur `/xmlrpc.php`. Ça tient même si WordPress est sale. Un plugin seul, non.
WAF Cloudflare : règle sur ce chemin. Purgez. Vérifiez que l’origine n’est pas joignable en direct avec xmlrpc ouvert (hostname d’origine).
Renommer le fichier est un mauvais souvenir de tutos : les mises à jour le recréent. Règle serveur.
Jetpack, apps et exceptions
Si vous utilisez vraiment l’app WordPress officielle ou Jetpack pour les stats / le backup, xmlrpc (ou l’API REST) peut être requis. Décidez. Une vitrine qui n’a jamais eu l’app : fermez. Un média qui publie depuis le téléphone : ouvrez, limitez (fail2ban, authentification forte, moins d’admins), surveillez les logs.
L’API REST (`/wp-json/`) est un autre endpoint. La fermer « pour durcir » casse Gutenberg et WooCommerce. Ce n’est pas le sujet xmlrpc. Ne les fusionnez pas dans une panique.
Les mots de passe d’application : autre tiroir, souvent oublié après un « on a fermé xmlrpc ».
Après un brute force : mots de passe et limites
Fermer xmlrpc n’invalide pas une session déjà ouverte ni un mot de passe déjà deviné. Panel, admin, 2FA ensuite. Limitez les tentatives sur wp-login aussi — les bots savent les deux chemins.
Les journaux du reverse proxy montrent l’IP réelle si les en-têtes sont bons. Sinon vous limitez l’IP du proxy et vous vous bloquez.
Un pic CPU « xmlrpc » peut être du brute force ou un pingback storm. Couper xmlrpc calme. Cherchez quand même si un login a réussi (admin créé à 3 h).
Ce que xmlrpc n’explique pas
Un kit phishing, un skimmer, un mu-plugin : autres portes (extension, upload, voisin). Fermer xmlrpc n’est pas un nettoyage. C’est une réduction de surface après ou pendant.
Safe Browsing ne se lève pas parce que xmlrpc est en 403. Réexamen : contenu propre.
Premiers gestes : ne commencez pas par xmlrpc si la home est un kit. Coupez le kit, puis durcissez.
Contrôle dans trente jours
Retestez le POST. Une MAJ de plugin « sécurité » a pu retirer le filtre. Une restauration a pu retirer la règle nginx. Un nouveau vhost n’a pas la règle.
Si vous devez le rouvrir pour Jetpack, documentez et surveillez les POST 200 anormaux.
Déclarer si vous ne savez pas poser une règle serveur chez votre hébergeur. On ne fournit pas d’exploit ; on ferme l’endpoint.