WordPress fait tourner une part considérable des sites web dans le monde. Le 17 juillet 2026, l'éditeur a publié un correctif d'urgence pour deux failles de son cœur, CVE-2026-60137 et CVE-2026-63030, dont la combinaison permet une exécution de code à distance sans authentification, sur une installation par défaut. Cet article a un but de sensibilisation et d'aide au correctif : il explique ce que ces failles permettent, qui est concerné, comment corriger et comment détecter une tentative. Il ne contient aucun mode opératoire d'attaque.
Avertissement : ForenShield n'est pas responsable de l'usage que vous faites de ces informations. Tester ou attaquer un site qui ne vous appartient pas, sans autorisation écrite, est une infraction pénale dans la plupart des pays.
Deux failles, une chaîne
Prise isolément, chaque faille est déjà sérieuse. Combinées, elles forment ce que plusieurs chercheurs ont nommé « wp2shell », du nom du dépôt qui en a démontré la portée.
| CVE | Nature | Rôle dans la chaîne |
|---|---|---|
| CVE-2026-60137 | Validation incorrecte du paramètre author__not_in de WP_Query, permettant une injection SQL |
Utilisée seule, elle exige qu'un plugin ou un thème transmette une donnée non fiable à ce paramètre |
| CVE-2026-63030 | Confusion des routes du point de terminaison de traitement par lot (batch) de l'API REST |
Permet d'atteindre le code vulnérable de WP_Query sans authentification, même sur un cœur WordPress sans aucun plugin |
Selon l'analyse d'Akamai, la combinaison des deux permet à un attaquant non authentifié d'exécuter du code arbitraire, sans plugin particulier ni configuration spéciale, dès que l'API REST est accessible. Le FAQ de Tenable précise deux conditions supplémentaires observées : l'absence de cache d'objets persistant, et au moins un article publié sur le site.
À retenir : contrairement à la plupart des incidents WordPress, cette chaîne ne nécessite ni plugin vulnérable ni identifiants volés. Un site avec le cœur WordPress seul, sans aucune extension, peut être touché.
Versions concernées par CVE-2026-63030 et CVE-2026-60137
| Branche | CVE-2026-60137 | CVE-2026-63030 | Version corrigée |
|---|---|---|---|
| 6.8.x (6.8.0 à 6.8.5) | Oui, si un plugin/thème transmet la donnée non fiable | Non concernée | 6.8.6 |
| 6.9.x (6.9.0 à 6.9.4) | Oui | Oui | 6.9.5 |
| 7.0.x (7.0.0 à 7.0.1) | Oui | Oui | 7.0.2 |
La branche 6.8 n'est exposée qu'à la CVE-2026-60137, et seulement si un plugin ou un thème installé transmet une donnée non fiable au paramètre concerné : le risque y dépend donc de l'écosystème d'extensions. Les branches 6.9 et 7.0 sont, elles, vulnérables à la chaîne complète sur une installation par défaut, sans aucun plugin.
Face à la gravité de la chaîne complète, WordPress a activé la mise à jour automatique forcée pour toutes les installations prises en charge sur les branches concernées, dès la publication des correctifs. La grande majorité des sites ont donc dû être corrigés sans action de leur administrateur. Il reste nécessaire de vérifier, en particulier pour les sites dont les mises à jour automatiques sont désactivées ou gérées manuellement.
Comment corriger et se protéger
- Vérifier la version installée dans le tableau de bord WordPress et la comparer à celle du tableau ci-dessus.
- Confirmer la mise à jour automatique, ou mettre à jour manuellement vers 6.8.6, 6.9.5 ou 7.0.2 si elle est désactivée.
- Si une mise à jour immédiate est impossible, mettre en place une mesure temporaire, en sachant qu'aucune ne remplace le correctif :
- bloquer, via le pare-feu applicatif, les requêtes vers
/wp-json/batch/v1et?rest_route=/batch/v1pour les visiteurs non authentifiés ; - installer une extension limitant l'accès non authentifié à l'API REST par lot.
- bloquer, via le pare-feu applicatif, les requêtes vers
- Revoir la configuration du cache d'objets : son absence fait partie des conditions observées de l'exploitation ; l'activer réduit une partie du risque sans corriger la faille.
- Après mise à jour, inspecter le site : comptes administrateur inconnus, extensions installées sans action de votre part, fichiers modifiés récemment dans l'arborescence du thème ou des extensions.
Aucun indicateur de compromission public et fiable n'était disponible au moment de la divulgation initiale. L'absence de trace ne garantit donc pas l'absence de compromission pour un site resté longtemps exposé : en cas de doute sur un site resté vulnérable plusieurs jours, une inspection manuelle reste la seule vérification sérieuse.
Détecter une tentative d'exploitation
Sans liste d'indicateurs de compromission officielle et complète à ce jour, la vigilance porte sur des signaux génériques :
- des requêtes vers le point de terminaison
batch/v1de l'API REST, en particulier sans en-tête d'authentification ; - l'apparition d'un compte administrateur que vous n'avez pas créé ;
- une extension installée ou activée sans intervention de l'équipe ;
- des journaux du serveur web montrant des requêtes répétées et automatisées peu après la divulgation (mi-juillet 2026) ou depuis.
Plusieurs éditeurs de pare-feu applicatif (Cloudflare, Akamai) ont publié des règles de détection dédiées à cette chaîne ; si votre hébergeur ou votre WAF en propose une, activez-la même après correction, pour repérer une tentative résiduelle.
Quand est-il légitime de tester la vulnérabilité ?
Un dépôt public, wp2shell, démontre cette chaîne. Son auteur précise qu'elle est réservée aux tests de sécurité autorisés et à l'usage pédagogique, sur des systèmes que l'on possède ou pour lesquels on dispose d'une autorisation écrite. Tester est acceptable uniquement dans l'un de ces cas :
- Votre propre installation WordPress, dans un environnement isolé, sans données réelles et sans exposition à Internet.
- Un test d'intrusion contractualisé, avec un périmètre écrit, des dates précises et l'accord signé du propriétaire du site.
- Un exercice de formation (CTF, plateforme de laboratoire) conçu pour cela.
Dans tous les autres cas, n'essayez pas. Exécuter du code sur le serveur d'un tiers, même « pour vérifier », constitue un accès frauduleux à un système d'information. Si vous constatez qu'un site tiers est vulnérable, prévenez son propriétaire ou l'hébergeur, sans tenter d'y accéder.
Ce que cet incident rappelle
- Garder les mises à jour automatiques activées sur WordPress : c'est ce mécanisme qui a protégé la majorité des sites dans cet épisode, avant même une intervention humaine.
- Ne pas se croire à l'abri parce qu'aucun plugin n'est installé : le cœur de WordPress peut lui-même porter une faille critique.
- Documenter les extensions et thèmes installés, pour repérer rapidement un ajout non autorisé après un incident.
Pour retrouver le détail d'une vulnérabilité par identifiant, la base CVE de ForenShield est disponible, et le calculateur CVSS aide à qualifier la criticité selon votre contexte.