Votre site WordPress affiche la dernière version disponible. Est-ce suffisant pour écarter tout risque avec wp2shell ? Non. La mise à jour corrige le code vulnérable. Elle n’efface ni un accès déjà posé par un attaquant avant le patch ni les traces d’une compromission passée. wp2shell désigne 2 failles chaînées du cœur WordPress, CVE-2026-63030 et CVE-2026-60137, corrigées en urgence le 17 juillet 2026 dans les versions 6.8.6, 6.9.5 et 7.0.2.
Un site marqué dangereux par Google Safe Browsing disparaît des résultats de recherche du jour au lendemain, avertissement rouge compris sur la fiche établissement Google Business Profile qui pointe vers lui. Ça rejoint exactement l’inquiétude qu’on entend chez beaucoup de dirigeants de TPE : le site n’est plus dans Google, sans qu’on sache pourquoi. Cette checklist va au-delà du bouton « mettre à jour » pour vérifier que votre site n’a pas déjà été touché.
Pourquoi la mise à jour seule ne suffit pas toujours
wp2shell est l’enchaînement de 2 bugs distincts, chacun porteur de son propre identifiant CVE. CVE-2026-63030 est une confusion de routes dans l’endpoint /wp-json/batch/v1 de l’API REST, notée 9.8 sur 10 en gravité. Elle a été introduite avec la version 6.9, sortie le 2 décembre 2025. CVE-2026-60137 est une injection SQL dans le paramètre author__not_in de la classe WP_Query, notée 5.9, présente depuis la version 6.8. Chaînées, ces 2 failles permettent à un attaquant non authentifié d’exécuter du code sur un site WordPress par défaut, sans compte ni interaction de l’administrateur.
Le patch referme la porte. Il ne dit rien de ce qui a pu entrer avant sa pose ; la première chose à vérifier reste donc la version réellement installée sur votre site.
Vérifier la version exacte de votre cœur WordPress
Ouvrez le tableau de bord, puis Mises à jour dans le menu de gauche. La version affichée doit être 6.8.6, 6.9.5 ou 7.0.2 selon la branche que vous suiviez avant l’incident. WordPress.org a forcé la mise à jour automatique sur les installations concernées dès le 17 juillet 2026. Un hébergement mutualisé avec l’auto-update désactivé côté serveur peut toutefois avoir manqué le coche. Si votre panneau affiche encore 6.9.4 ou 7.0.1, la faille reste ouverte sur votre site.
Savoir si l’exécution de code était vraiment possible chez vous
Toutes les installations vulnérables n’étaient pas exposées au même degré. Selon l’analyse publiée par Cloudflare, la chaîne complète menant à l’exécution de code n’est atteignable que lorsque aucun cache objet persistant n’est actif sur le site. Un cache objet géré par Redis ou Memcached, courant chez les hébergements mutualisés orientés WordPress, réduisait donc de fait la fenêtre de risque. La configuration inverse existe aussi et reste fréquente sur les petites installations tournant sans cache dédié. Demandez à votre hébergeur si un cache objet persistant était actif sur votre compte avant le 17 juillet 2026 : la réponse cadre la suite de la vérification.
Chercher les signes d’une compromission antérieure au patch
C’est l’étape que la plupart des checklists sautent, alors qu’elle est la plus importante si votre site tournait en 6.9.x ou 7.0.x sans cache objet avant le 17 juillet. Des chercheurs de Wiz ont observé plusieurs comportements post-exploitation après l’abus de wp2shell, dont l’installation d’un faux plugin CMSmap qui dissimule en réalité un webshell de 150 ko. Wiz a aussi relevé au moins un cas de trojan d’accès distant Overlord, déployé en langage Go. Passez ces 3 points en revue dans l’ordre :
- La liste des utilisateurs administrateurs, dans Utilisateurs, en cherchant un compte que personne dans l’équipe ne reconnaît.
- La liste des extensions installées, dans Extensions, en vérifiant chaque plugin dont le nom ne correspond à aucune installation volontaire, CMSmap en tête.
- Les fichiers modifiés récemment sur le serveur via le gestionnaire de fichiers de l’hébergeur, trié par date de dernière modification.
Un compte admin inconnu ou une extension jamais installée volontairement signale une compromission qui a précédé la mise à jour. Dans ce cas, patcher ne suffit pas : il faut supprimer l’accès, changer tous les mots de passe et, sur un cas confirmé, restaurer depuis une sauvegarde antérieure au 17 juillet.
Les chercheurs de Wiz, Shahar Dorfman et Gili Tikochinski, notent avoir également observé une activité de scan à fort volume sans exploitation ultérieure, ce qui suggère des campagnes de scan opportunistes cherchant à repérer des cibles vulnérables, aux côtés d’activités de scan de sécurité légitimes.
Réduire la surface de l’API REST en complément
Une fois la version confirmée et l’absence de compromission vérifiée, une mesure supplémentaire limite le risque sur une future faille du même type : restreindre l’accès public à l’endpoint batch de l’API REST via une extension de sécurité gratuite comme Wordfence ou Jetpack Protect, toutes deux capables de bloquer une route spécifique sans toucher au reste du site. Cette mesure peut casser une intégration tierce qui utilise légitimement cet endpoint, rare en pratique sur un site de TPE, donc traitez-la comme une précaution temporaire plutôt qu’un réglage définitif.
Les pièges qui laissent un site vulnérable malgré la mise à jour affichée
2 situations trompent régulièrement les propriétaires de sites persuadés d’être à jour. La première : un plugin de cache de page, différent du cache objet évoqué plus haut, qui sert une version figée du tableau de bord et affiche un ancien numéro de version même après l’application du correctif côté serveur. Videz le cache du plugin puis rechargez la page Mises à jour pour confirmer le numéro réel. La seconde : un hébergement mutualisé qui applique les correctifs de sécurité critiques avec un délai de plusieurs jours par rapport à l’annonce officielle de WordPress.org, le temps de tester la compatibilité sur son parc de serveurs. Contactez le support pour connaître la date exacte du déploiement sur votre compte plutôt que de vous fier au calendrier général.
Pas besoin d’un consultant à 800 euros la journée pour mener cette vérification. Les 5 étapes ci-dessus se font depuis le tableau de bord WordPress et l’espace client de l’hébergeur, avec des extensions gratuites pour la partie protection.
Questions fréquentes sur wp2shell
Wp2shell touche-t-il tous les sites WordPress ? Non. La chaîne complète d’exécution de code ne concerne que les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. L’injection SQL isolée, moins critique, remonte à la version 6.8.0.
Un scan de sécurité gratuit suffit-il à détecter une compromission ? Un scan comme celui de Wordfence détecte les signatures connues, dont le faux plugin CMSmap identifié par Wiz. Il ne remplace pas la vérification manuelle des comptes administrateurs, qu’aucun scanner automatique ne juge fiablement seul.
Faut-il changer tous les mots de passe après une simple mise à jour, sans signe de compromission ? Pas nécessairement si les 3 vérifications de la section précédente ne remontent rien d’anormal. Changez les mots de passe uniquement en cas de doute confirmé, pour éviter une rotation inutile sur chaque alerte de sécurité WordPress.
WordPress affichera un jour un autre numéro de version, avec son lot de nouveaux correctifs d’urgence. La checklist, elle, reste la même.
Laisser un commentaire