Faille WordPress wp2shell (CVE-2026-63030) : vérifier et protéger votre site
En juillet 2026, WordPress a corrigé wp2shell, une faille du cœur qui permet de prendre le contrôle d'un site sans mot de passe. Pas besoin d'extension vulnérable ni de compte administrateur : une installation standard en 6.9 ou 7.0 suffit. Des codes d'exploitation circulent publiquement depuis le lendemain du correctif.
Trois mois plus tard, beaucoup de sites tournent encore sur une version vulnérable : mise à jour automatique désactivée, échec silencieux, préproduction oubliée. Voici ce qu'il faut savoir, comment vérifier votre site et comment vous protéger durablement.
wp2shell, c'est quoi exactement ?
wp2shell n'est pas une faille unique mais l'enchaînement de deux vulnérabilités du cœur de WordPress. Prises séparément, elles sont limitées ; combinées, elles donnent une exécution de code à distance (RCE) sans authentification, notée 9,8/10 (CVSS 3.1, WPScan).
- CVE-2026-63030 — la porte d'entrée. Le point d'entrée « batch » de l'API REST, apparu avec WordPress 6.9, interprète mal certaines routes. Un visiteur anonyme peut ainsi atteindre du code qui devrait lui être fermé.
- CVE-2026-60137 — le levier. Le paramètre
author__not_indeWP_Querypermet une injection SQL. C'est ce code, rendu accessible par la première faille, que l'attaquant exploite.
Le résultat : un attaquant envoie quelques requêtes HTTP et peut exécuter ses propres commandes sur le serveur. Il peut alors déposer une porte dérobée, voler la base clients, injecter du spam SEO ou se servir du site pour en attaquer d'autres.
Votre version est-elle concernée ?
Tout site en WordPress 6.9 ou 7.0 non mis à jour est exposé à la chaîne complète. La branche 6.8 n'est touchée que par l'injection SQL.
| Branche | Versions vulnérables | Exposition | Version corrigée | | --- | --- | --- | --- | | 7.1 (bêta) | 7.1 bêta 1 | Chaîne complète (RCE) | 7.1 bêta 2 | | 7.0 | 7.0.0 à 7.0.1 | Chaîne complète (RCE) | 7.0.2 | | 6.9 | 6.9.0 à 6.9.4 | Chaîne complète (RCE) | 6.9.5 | | 6.8 | jusqu'à 6.8.5 | Injection SQL seule (CVE-2026-60137) | 6.8.6 |
Les extensions et thèmes ne changent rien : la faille est dans le cœur. Un site « minimaliste » sans aucune extension est aussi vulnérable qu'un autre. WordPress a forcé la mise à jour automatique sur les sites qui l'acceptent, mais elle échoue parfois sans prévenir (droits sur les fichiers, disque plein, mises à jour désactivées par un prestataire).
Comment vérifier votre site
Commencez par la version, puis cherchez des traces d'intrusion si le site est resté vulnérable après le 17 juillet.
1. La version installée. Dans l'administration, menu Tableau de bord → Mises à jour. En ligne de commande : wp core version. Ne vous fiez pas à la promesse d'une mise à jour automatique : vérifiez.
2. Les traces dans les journaux. Recherchez dans les logs du serveur web, du proxy ou du pare-feu applicatif les appels à :
/wp-json/batch/v1?rest_route=/batch/v1
Des appels anonymes en masse vers ces routes, surtout en POST, doivent alerter.
3. Les signes d'une compromission.
- fichiers PHP récents dans
wp-content/uploads, les thèmes, les extensions ou à la racine ; - comptes administrateurs, sessions ou mots de passe d'application inconnus ;
- extensions ou thèmes ajoutés ou réactivés sans raison ;
- tâches planifiées (cron) suspectes ;
- fichiers du cœur modifiés :
wp core verify-checksums; - pics de CPU, connexions sortantes ou processus inhabituels.
Comment vous protéger
La seule vraie protection est la mise à jour. Faites-la proprement, en quelques étapes :
- Listez tous vos sites, y compris les préproductions, les sites de test et les vieilles installations oubliées.
- Faites une sauvegarde et vérifiez qu'elle se restaure.
- Mettez à jour vers 7.0.2, 6.9.5 ou 6.8.6 selon votre branche (idéalement d'abord sur une préproduction : voir staging + déploiement WordPress sur adgents.cloud).
- Contrôlez la version effectivement déployée.
- Videz les caches et testez les parcours essentiels : connexion, formulaires, paiement, publication.
- Analysez les journaux pour vérifier que personne n'est entré avant le correctif.
Mise à jour impossible tout de suite ? Bloquez les accès anonymes aux routes batch/v1 via votre pare-feu applicatif (WAF) ou une règle serveur. C'est une rustine : elle peut casser des usages légitimes de l'API et ne remplace pas le correctif.
Site déjà compromis ? Ne vous contentez pas de supprimer le fichier suspect. Isolez le site, conservez les preuves, repartez d'une base saine, restaurez des données vérifiées et changez tous les secrets : base de données, comptes admin, accès hébergement, clés d'API, sels de wp-config.php.
Pour aller plus loin sur le durcissement : Sécuriser WordPress : hardening + WAF + sauvegardes (guide 2026).
Pourquoi l'hébergement compte autant que le code
wp2shell montre qu'un site WordPress bien entretenu peut être vulnérable du jour au lendemain. Ce qui fait la différence, c'est la vitesse de réaction et la capacité à revenir en arrière. C'est ce pour quoi adgents.cloud est conçu :
- un environnement de préproduction en un clic, pour tester une mise à jour de sécurité avant de l'appliquer en production ;
- des sauvegardes chiffrées et externalisées, stockées hors du serveur, pour restaurer un site sain si le pire arrive ;
- une surveillance HTTP/HTTPS continue, avec alerte par email en cas d'indisponibilité ou de certificat proche de l'expiration ;
- des comptes système isolés par site : une instance compromise ne donne pas accès aux autres ;
- un hébergement en France, facturé à l'heure selon les ressources réellement allouées.
Lancez-vous avec WordPress
WordPressLe CMS le plus populaire au mondeEn résumé
Si votre site tourne en WordPress 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1, mettez-le à jour aujourd'hui, puis vérifiez qu'il n'a pas été visité entre-temps. La faille est publique et exploitée par des robots qui scannent le web en continu.
Vous voulez héberger vos sites WordPress sur une plateforme qui vous laisse tester, sauvegarder et restaurer sans stress ? Créez votre instance sur adgents.cloud.