Attaques XML-RPC WordPress : brute force et pingback
`xmlrpc.php` sert aux apps mobiles et aux attaques (brute force multicall, pingback). Si vous ne l'utilisez pas, désactivez-le après le nettoyage. Pendant l'incident, ce n'est presque jamais la seule porte — les logs pleins de xmlrpc ne disent pas « c'est ça ».
xmlrpc.php sert aux apps et aux attaques. Si vous ne l'utilisez pas, désactivez-le après nettoyage. Pendant l'incident, ce n'est presque jamais la seule porte.
À quoi xmlrpc sert encore
L'app WordPress officielle, certains Jetpack, IFTTT, des outils de pub anciens. Si personne n'y touche, vous pouvez le fermer. Si l'app métier s'en sert, fermez le multicall, pas forcément tout le fichier.
WordPress moderne préfère l'API REST (`wp-json`). Beaucoup de sites n'ont plus besoin de xmlrpc. C'est une surface gratuite pour les bots.
Des milliers de POST `/xmlrpc.php` sont quotidiens. Ça n'explique pas un générateur de pharmacies. Ça peut expliquer un user admin si un mot de passe faible a cédé via `system.multicall` — les limiteurs qui ne regardent que wp-login laissent passer. Un `xmlrpc.php` de 80 Ko n'est plus le fichier officiel. Une copie dans uploads est une porte déguisée. Cherchez les 200 authentifiés dans les logs, pas le volume.
Avant de Deny, une requête `system.listMethods` vous dit si le fichier répond encore comme le cœur. Un 200 avec une liste de méthodes énorme + un poids fichier anormal : remplacez par le zip d'abord. Un 403 déjà là : cherchez les copies, le roman n'est pas à la racine.
Les copies hors racine se cherchent au grep, pas au Deny unique.
Multicall et brute force
Une requête `system.multicall` teste des centaines de mots de passe d'un coup. Plus efficace qu'un POST wp-login. Les plugins de limitation login qui ne regardent que `wp-login.php` laissent passer ça. D'où des admins créés « sans 404 sur wp-login ».
Si une connexion a réussi, vous avez un user. La brute force n'est alors plus du bruit. Brute force wp-login.
Si vous gardez xmlrpc pour Jetpack, coupez au moins `system.multicall` (filtre ou WAF). La limitation login sur wp-login seul est un angle mort documenté depuis des années. Après une réussite, traitez comme une entrée admin : fichiers déposés, pas « juste un mot de passe ».
WordPress moderne préfère wp-json. Beaucoup de sites n'ont plus besoin de xmlrpc : c'est une surface gratuite pour les bots. Fermez-la après le clean, pas comme seul geste du soir.
Pingback et DDoS rebond
Les pingbacks abusent votre site comme relais. Charge CPU, ticket hébergeur « resource abuse », pas forcément un shell. Couper xmlrpc ou les pingbacks règle ce ticket-là. Ce n'est pas un nettoyage malware.
Lire les logs sans conclure trop vite
Des milliers de POST `/xmlrpc.php` : quotidien sur un WP visible. Ça n'explique pas un générateur de pharmacies. Ça peut expliquer un user admin si un mot de passe faible a cédé. Cherchez dans les logs une réponse 200 authentifiée, pas seulement le volume.
Un `xmlrpc.php` de 80 Ko au lieu de ~3 : ce n'est plus le fichier officiel. Comparez au zip. Une copie dans `uploads/xmlrpc.php` : porte dérobée déguisée. PHP uploads.
Les 200 authentifiés se voient aussi dans les e-mails « nouvel utilisateur » et la table users. xmlrpc n'écrit pas toujours une ligne claire « success » dans l'access.log selon le format. Croisez. Une réussite = incident complet, pas un Deny et on oublie.
Désactiver proprement
Après le clean : filtre `xmlrpc_enabled` __return_false, ou règle serveur `Deny` sur `/xmlrpc.php`, ou réglage Wordfence / Solid. Testez l'app si vous l'utilisez.
Pendant l'incident, bloquer xmlrpc n'enlève pas le mu-plugin. Ne vous arrêtez pas là. Par où commencer.
Pendant l'incident, un 403 xmlrpc n'enlève pas le mu-plugin. Notez-le comme tâche J+1, après la chasse. Par où commencer.
Copies de xmlrpc ailleurs
Les attaquants déposent `xmlrpc.php` dans des dossiers pour contourner un Deny à la racine. Grep le nom. Les Deny doivent couvrir ou, mieux, le fichier officiellement réduit + pas de copies.
Grep `xmlrpc.php` sur tout le compte. Les Deny à la racine se contournent par une copie dans `uploads` ou `wp-includes`. Le fichier officiel se remplace par le zip, les copies se retirent.
REST API n'est pas xmlrpc
`/wp-json/wp/v2/users` qui liste les logins : autre surface. On peut la restreindre. La fermer entièrement casse Gutenberg et Woo. Ce n'est pas le sujet xmlrpc ; ne les confondez pas dans un `.htaccess` de panique.
Après : ce qu'il reste à chercher
Users, plugins, thème, uploads. xmlrpc est une commodité d'attaque, rarement le roman entier.
Désactivez après le clean (filtre ou Deny), pas comme seul geste. Testez Jetpack / l'app si vous les utilisez. Une MAJ WordPress recrée le fichier : un delete ne tient pas. Guide WordPress, créer un espace.
REST API, Jetpack, et pingback
`/wp-json/wp/v2/users` qui liste les logins est une autre surface. On peut la restreindre. La fermer entièrement casse Gutenberg et Woo. Ne les confondez pas dans un .htaccess de panique. Jetpack a souvent besoin de xmlrpc : vérifiez avant un Deny brutal.
Les pingbacks abusent le site comme relais : charge CPU, ticket « resource abuse », pas forcément un shell. Couper xmlrpc ou les pingbacks règle ce ticket-là. Ce n'est pas un nettoyage malware.
Multisite : un fichier, tout le réseau. Multisite. Créer un espace.
Décider : tout fermer, ou seulement multicall
Personne n'utilise l'app ni Jetpack : Deny / filtre, après le clean. Jetpack stats seulement : demandez à Jetpack ce qui reste nécessaire, souvent on peut réduire. App métier : fermez multicall, gardez le reste, mot de passe long, 2FA. Dans les trois cas, remplacez un xmlrpc.php trop gros par le zip, retirez les copies.
Les logs pleins ne sont pas le roman. Une réussite l'est. Brute force. Créer un espace.