Piraté via WP2Shell : pourquoi mettre à jour WordPress ne nettoie pas votre site

Le 17 juillet 2026, WordPress a publié en urgence les versions 6.9.5 et 7.0.2 pour corriger WP2Shell, une chaîne de deux failles du cœur du CMS permettant de prendre le contrôle total d'un site sans authentification. Quelques heures plus tard, des exploits publics circulaient déjà. Le 21 juillet, l'exploitation de masse était confirmée par plusieurs équipes de recherche.

Si vous lisez cet article, c'est probablement que votre site était dans la fenêtre de tir : version vulnérable entre le 17 juillet et votre mise à jour. La mauvaise nouvelle, c'est que mettre à jour ne nettoie rien. La bonne, c'est que les traces laissées par les attaquants se trouvent, à condition de savoir où chercher. Voici la méthode complète.

Le rappel des faits, en 30 secondes

WP2Shell enchaîne deux vulnérabilités du cœur WordPress : CVE-2026-63030 (confusion de route sur l'endpoint REST /wp-json/batch/v1) et CVE-2026-60137 (injection SQL dans WP_Query). Combinées, elles donnent une exécution de code à distance sans compte ni mot de passe, sur les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1.

La chronologie est brutale : correctifs publiés le 17 juillet, preuve de concept publique dans les heures qui suivent, outils d'exploitation automatisés sur plusieurs dépôts publics dès le 19 juillet, exploitation généralisée constatée le 21 juillet. Wordfence a observé les premières tentatives le soir même de la publication du patch. Pour la partie prévention (versions, blocage de l'endpoint, règles WAF), on a détaillé tout ça dans notre article sur la sécurisation face à WP2Shell. Ici, on parle de l'après : votre site a été exposé, que faire.

Pourquoi la mise à jour ne suffit pas

Une mise à jour de sécurité ferme la porte d'entrée. Elle n'expulse pas ceux qui sont déjà entrés. Or les chercheurs qui suivent l'exploitation de WP2Shell ont documenté précisément ce que font les attaquants une fois dans la place :

• Dépôt de webshells : de petits fichiers PHP cachés qui offrent un accès permanent au serveur, indépendant de la faille d'origine.
• Création de comptes administrateurs : les honeypots de watchTowr ont enregistré plus de 100 comptes de porte dérobée créés par des attaquants différents, avec des variantes de l'outillage public.
• Installation de plugins malveillants : un faux plugin est une persistance discrète qui survit aux mises à jour du cœur.
• Vol des identifiants hachés : l'injection SQL permet d'exfiltrer la table des utilisateurs, mots de passe hachés compris.

Chacun de ces quatre éléments survit sans problème au passage en 7.0.2. Un site patché mais backdooré reste un site compromis : il peut servir de relais de spam, héberger du phishing, rediriger vos visiteurs ou être revendu à d'autres groupes criminels des semaines plus tard.

Les 6 vérifications à faire maintenant

1. La liste des comptes administrateurs

Avec WP-CLI :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Tout compte que vous n'avez pas créé vous-même, en particulier avec une date d'inscription postérieure au 17 juillet, est un signal de compromission avérée. Ne vous contentez pas de le supprimer : on explique pourquoi dans notre article dédié aux comptes admin fantômes.

2. Les fichiers PHP inattendus

Les webshells se logent en priorité dans les répertoires d'upload et de cache, où un fichier PHP n'a rien à faire :

find wp-content/uploads wp-content/cache -name "*.php"
find . -name "*.php" -newermt "2026-07-17" -not -path "./wp-includes/*" -not -path "./wp-admin/*"

Attention aux noms de fichiers commençant par un point (.wp-log.php, .bd.php), invisibles avec un simple ls. Si vous en trouvez, lisez notre guide sur les webshells down.php et .wp-log.php avant de supprimer quoi que ce soit.

3. La liste des plugins et mu-plugins

wp plugin list --fields=name,status,version
ls -la wp-content/mu-plugins/

Les mu-plugins (must-use plugins) se chargent automatiquement et n'apparaissent pas dans l'interface d'administration classique : c'est une cachette appréciée. Tout plugin que vous ne reconnaissez pas doit être examiné.

4. Les logs du serveur

Cherchez dans vos logs d'accès les requêtes vers l'endpoint exploité, entre le 17 juillet et votre mise à jour :

grep -E "batch/v1|rest_route=/batch" access.log
grep "author__not_in" access.log

Des requêtes POST vers /wp-json/batch/v1 venant d'IP inconnues sur cette période sont la signature de tentatives d'exploitation. Leur présence ne prouve pas que l'attaque a réussi, mais leur volume et les codes de réponse (200 plutôt que 403) donnent une idée sérieuse du risque.

5. Mots de passe et salts

Puisque l'injection SQL permettait de lire les identifiants hachés, considérez les mots de passe de tous les comptes comme exposés. Réinitialisez-les, et régénérez les salts dans wp-config.php pour invalider toutes les sessions et cookies existants :

wp config shuffle-salts

6. Les tâches planifiées

wp cron event list
crontab -l

Une tâche cron malveillante peut retélécharger un webshell des heures après le nettoyage. Vérifiez aussi bien le cron WordPress que le cron système de votre hébergement.

Les signes qui confirment la compromission

Au-delà des vérifications techniques, certains symptômes visibles ne trompent pas : vos visiteurs sont redirigés vers des sites douteux, une fausse page de vérification s'affiche avant votre contenu, Google Search Console vous signale des pages que vous n'avez jamais créées, ou votre site est marqué comme dangereux dans Chrome. Si l'un de ces symptômes vous parle, votre cas est détaillé dans notre article sur les redirections et fausses pages de vérification.

Le nettoyage complet, dans l'ordre

Si une seule des vérifications ci-dessus a donné un résultat positif :

1. Sauvegardez l'état actuel du site (fichiers + base) comme pièce à conviction, à part de vos sauvegardes saines.
2. Passez le site en maintenance pour protéger vos visiteurs.
3. Supprimez webshells, comptes pirates, plugins malveillants et tâches cron suspectes, dans cet ordre et en une seule session.
4. Réinstallez le cœur WordPress et les plugins depuis les sources officielles (les fichiers infectés peuvent se cacher dans des fichiers légitimes modifiés).
5. Réinitialisez tous les mots de passe et les salts, en dernier, une fois les portes dérobées fermées.
6. Surveillez les fichiers et les logs pendant les 30 jours qui suivent : une réinfection rapide signifie qu'une porte a été oubliée.

La méthode générale de nettoyage d'un WordPress piraté (blacklist Google comprise) est détaillée pas à pas dans notre guide complet de détection et nettoyage. Et si vous préférez déléguer, notre service de suppression de virus et malware couvre exactement ce scénario : nettoyage complet, hardening, et monitoring 30 jours inclus.

FAQ

J'ai mis à jour vers 7.0.2 dès le 17 juillet, suis-je tranquille ?

Probablement, mais pas certainement : Wordfence a observé des tentatives d'exploitation le soir même de la publication des correctifs. Si votre mise à jour est passée dans les toutes premières heures (mises à jour automatiques activées), votre fenêtre d'exposition était minime. Faites quand même les vérifications 1 et 2, elles prennent dix minutes.

Mon hébergeur dit que le site est sain, ça suffit ?

Les scanners d'hébergeurs détectent les signatures connues de malwares. Un webshell obfusqué récent, un compte admin discret ou un plugin malveillant inédit passent régulièrement sous leurs radars. Un scan hébergeur négatif est un bon signal, pas une preuve.

Faut-il tout réinstaller de zéro ?

Pas nécessairement. Une réinstallation propre du cœur et des plugins depuis les sources officielles, combinée à un examen de la base de données et des répertoires d'upload, suffit dans la majorité des cas. La réinstallation complète depuis une sauvegarde n'a de sens que si la sauvegarde est antérieure au 17 juillet et que vous acceptez de perdre le contenu créé depuis.

Combien coûte un nettoyage professionnel ?

Chez nous, l'audit initial est gratuit : vous savez d'abord si votre site est réellement compromis. Le nettoyage complet se situe entre 690€ et 1890€ HT selon l'étendue de l'infection, monitoring 30 jours inclus. Le détail est sur la page du service.

Sources primaires

• TechCrunch, « Hackers are exploiting recently patched WordPress bugs, putting millions of websites at risk ».
• Field Effect, « WordPress wp2shell attacks escalate following public PoC release ».
• Dark Reading, « 'WP2Shell' Opens Millions of WordPress Sites to Remote Takeover ».
• Malwarebytes, « What happens if you visit a WordPress site hacked through wp2shell ».