Le 17 juillet 2026, l’équipe WordPress a publié en urgence la version 7.0.2, accompagnée des correctifs 6.9.5 et 6.8.6. La raison : une chaîne de vulnérabilités baptisée wp2shell, combinant deux failles dans le cœur même de WordPress. Résultat possible pour un attaquant ? Une exécution de code à distance sans authentification, sur n’importe quel site tournant sur une version exposée. Sans plugin tiers. Sans configuration exotique. Une installation WordPress standard suffisait.
A lire aussi : Votre page de devis est lente sur telephone : ce que ca vous coute
Ce qu’il faut retenir :
- WordPress core lui-même était vulnérable en juillet 2026, indépendamment de tout plugin installé.
- La chaîne wp2shell combinait une injection SQL et une confusion de route REST pour atteindre une RCE non authentifiée.
- Les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 étaient dans la plage exposée : vérifiez votre branche exacte.
- WordPress a activé des mises à jour forcées, signal rare indiquant un niveau de risque jugé exceptionnel.
- Un site non mis à jour reste exploitable longtemps après la publication du correctif, car les scans automatisés ciblent les versions connues.
La chaîne wp2shell : comment deux failles deviennent une compromission totale
La chaîne wp2shell repose sur deux CVE distincts : CVE-2026-60137 et CVE-2026-63030. Pris séparément, chacun aurait un impact limité. Combinés, ils permettent à un attaquant sans aucun compte valide de prendre le contrôle complet du serveur.
Le premier défaut est une injection SQL dans WP_Query, un composant fondamental du core WordPress utilisé pour construire toutes les requêtes de base de données. Le second est une confusion de route dans l’API REST, plus précisément dans le endpoint de traitement par lot /wp-json/batch/v1. Ce endpoint mal validé permettait de manipuler l’ordre d’exécution des requêtes et d’exploiter la faille SQL dans un contexte privilégié.
À lire aussi : GiveWP : la faille d’injection d’objet ouvre la porte à du code malveillant
A lire aussi : Module de reservation en panne le samedi soir : ce qui lache vraiment
A lire aussi : Votre formulaire de contact WordPress n'envoie plus rien : les 6 causes
Le mot « chaîne » est donc clé. Le CIS Security Advisory parle explicitement d’une « vulnerability chain in WordPress core » capable de mener à une exécution de code à distance. Ce schéma d’attaque composite est plus difficile à détecter et plus difficile à mitiger qu’une faille isolée.
Les chercheurs identifiés comme reporters sont TF1T, dtro et haongo pour la faille SQL, et Adam Kues d’Assetnote / Searchlight Cyber pour la confusion REST. Les deux signalements ont transité par le portail HackerOne officiel de WordPress core, confirmant qu’il existe un canal structuré de divulgation responsable distinct de l’écosystème des plugins.
Pourquoi une faille core est différente d’une faille de plugin
Dans la grande majorité des incidents WordPress, la faille se trouve dans un plugin tiers. La logique de défense est alors simple : identifier le plugin, le désactiver ou le mettre à jour, et l’exposition cesse. La surface d’attaque est limitée aux sites utilisant ce plugin précis.
Avec une vulnérabilité WordPress core, cette logique s’effondre. L’attaquant n’a pas besoin que le site utilise un plugin particulier. Il suffit que le site tourne sur une version exposée. Un blog minimaliste sans aucune extension installée, un site vitrine en configuration stock, un WordPress fraîchement installé : tous pouvaient être visés.
Attention : supprimer vos plugins ou choisir un thème léger ne réduit pas votre exposition face à une faille core. Seule la mise à jour vers une version corrigée ferme réellement la porte.
La portée est mécaniquement plus large. Selon les synthèses disponibles, WordPress propulse environ 41,2 % de tous les sites web dans le monde et représente 59,1 % de part de marché CMS parmi les sites dont le CMS est identifié. Une faille dans le core touche potentiellement cette base entière, pas un sous-ensemble d’utilisateurs d’une extension.
Pour les équipes qui gèrent des sites de production, cela change aussi la remédiation. Désactiver un plugin prend quelques secondes. Mettre à jour WordPress core sur un environnement contraint — avec des tests de régression, des validations de compatibilité, des procédures de staging — prend du temps. Ce délai est précisément la fenêtre d’exploitation.
Pour comparer les versions touchées et les correctifs disponibles, voici un tableau de référence basé sur les informations publiées :
| Branche | Versions vulnérables | Version corrigée | Type de faille |
|---|---|---|---|
| 6.8.x | 6.8.0 à 6.8.5 | 6.8.6 | Injection SQL (CVE-2026-60137) |
| 6.9.x | 6.9.0 à 6.9.4 | 6.9.5 | Chaîne complète SQLi + RCE |
| 7.0.x | 7.0.0 à 7.0.1 | 7.0.2 | Chaîne complète SQLi + RCE |
Les mises à jour forcées : un signal d’alarme rare
Face à la gravité de l’incident, WordPress a pris une décision inhabituelle : activer les mises à jour automatiques forcées pour les sites sur les versions affectées. Ce mécanisme existe dans WordPress, mais son déclenchement reste rare et réservé aux situations où l’équipe core juge le risque trop élevé pour le laisser à la discrétion des administrateurs.
En pratique, cela signifie que des sites ont été mis à jour automatiquement sans intervention manuelle de leur propriétaire. WordPress a jugé que la réduction du délai d’exposition primait sur le contrôle habituel des administrateurs. Pour les sites où les mises à jour automatiques étaient désactivées, le tableau de bord proposait une action directe via Dashboard → Updates → Update Now, avec un lien de téléchargement manuel en complément.
Trois semaines après cette première vague, le 6 août 2026, WordPress a publié la version 7.0.3 avec 12 correctifs de sécurité supplémentaires. Les catégories couvertes incluent des failles de type XSS, élévation de privilèges, SSRF, injection CSS et divulgation d’informations. Ce rythme soutenu — deux releases de sécurité majeures en moins d’un mois — confirme que le core était entré dans une phase de durcissement actif.
Pour aller plus loin sur l’utilisation des outils de sécurité disponibles, comparez les meilleurs plugins IA pour la sécurité WordPress et leur capacité à détecter ces types d’attaques en temps réel.
Ce que risque concrètement un site compromis
Une exécution de code à distance non authentifiée ne s’arrête pas à la prise de contrôle du fichier wp-config.php. L’impact potentiel s’étend sur plusieurs niveaux :
- Lecture et exfiltration de la base de données : identifiants utilisateurs, données clients, commandes WooCommerce, emails.
- Modification du contenu : injection de liens malveillants, défacement, redirection vers des sites tiers.
- Installation de backdoors : persistance sur le serveur même après une mise à jour du core.
- Pivot vers l’infrastructure : sur un hébergement mutualisé, l’accès au serveur peut exposer d’autres sites hébergés sur le même compte.
- Impact SEO : Google détecte et blackliste les sites compromis, entraînant une désindexation et une perte de trafic organique.
Conseil : si vous suspectez une compromission, ne vous contentez pas de mettre à jour le core. Renouvelez les clés secrètes dans
wp-config.php, vérifiez l’intégrité des fichiers core et auditez les comptes administrateurs créés récemment.A lire aussi : Un paiement WooCommerce qui echoue, c'est une vente perdue : les causes
La CISA a d’ailleurs ajouté les deux CVE de la chaîne wp2shell à son catalogue Known Exploited Vulnerabilities — un signal fort que l’exploitation était réelle et active, pas seulement théorique. Le SANS Institute a relayé l’urgence de patcher dès le 21 juillet 2026, insistant sur la nature activement exploitée des failles.
Pour les environnements qui ne peuvent pas être patchés immédiatement, plusieurs mesures d’urgence peuvent réduire l’exposition : bloquer les requêtes anormales sur /wp-json/batch/v1 via un WAF, surveiller les logs d’accès pour des patterns inhabituels, et s’assurer que des sauvegardes récentes sont disponibles. En cas de compromission avérée, la restauration de site WordPress reste souvent la solution la plus fiable pour repartir sur une base saine.
Discipline de mise à jour : le vrai facteur de risque en 2026
Les compilations disponibles pour 2026 indiquent qu’environ 40 % des sites WordPress n’avaient pas été mis à jour au cours des six derniers mois précédant l’incident. Cette proportion illustre pourquoi une faille core peut rester exploitable longtemps après la publication du correctif : les scans automatisés identifient les versions exposées et les ciblent méthodiquement.
WordPress maintient plusieurs branches actives simultanément. En juillet 2026, les correctifs ont dû être déployés sur trois branches : 6.8.x, 6.9.x et 7.0.x. Cela signifie que vérifier si « WordPress est à jour » de façon générique ne suffit pas. Un administrateur doit connaître sa branche exacte et confirmer qu’il est sur la version corrigée de cette branche.
Les environnements de préproduction constituent un angle mort fréquent. Un site de staging oublié, accessible publiquement, sur une version vulnérable, représente une porte d’entrée exploitable même si le site de production est corrigé.
Pour anticiper ces cycles de mises à jour et automatiser une partie de la surveillance, les meilleurs plugins IA pour la maintenance WordPress en 2026 offrent des capacités de détection et d’alerte adaptées à ces scénarios. Une révision technique WordPress régulière permet aussi d’identifier les branches de versions en retard avant qu’une faille ne soit annoncée.
Conclusion
La chaîne wp2shell a montré en juillet 2026 que le core WordPress peut lui-même devenir le vecteur d’une compromission totale. Deux failles combinées, une injection SQL et une confusion de route REST, ont suffi pour atteindre une exécution de code à distance sans aucune authentification. L’absence de plugin vulnérable n’offrait aucune protection.
La réponse de WordPress a été à la hauteur de la gravité : mises à jour forcées, correctifs sur trois branches simultanées, et une deuxième vague de 12 correctifs moins de trois semaines plus tard. Ces signaux montrent qu’une vulnérabilité WordPress core n’est pas un incident comme les autres. La surface exposée est potentiellement toute la base installée mondiale.
La discipline de mise à jour reste le premier rempart. Vérifiez votre branche, confirmez votre version, et ne laissez pas vos environnements de staging devenir des portes dérobées oubliées.
FAQ
Qu’est-ce qu’une vulnérabilité WordPress core exactement ?
Une vulnérabilité WordPress core est une faille présente dans le code officiel de WordPress lui-même, pas dans un plugin ou un thème tiers. En 2026, la chaîne wp2shell en est l’exemple le plus documenté : elle combinait une injection SQL dans WP_Query et une confusion de route dans l’API REST, deux composants natifs du CMS. Un site WordPress standard, sans aucune extension ajoutée, pouvait être exposé si sa version se trouvait dans la plage 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1.
Mon site sans plugin est-il vraiment vulnérable ?
Oui, si la version installée se trouve dans les plages affectées. La chaîne wp2shell cible le core de WordPress, pas ses extensions. Une installation de base sans plugin supplémentaire était exposée à une compromission totale si elle tournait sur une version vulnérable et était accessible sur Internet. L’absence de plugin ne constitue aucune barrière contre une faille native de la plateforme.
Comment vérifier si ma version WordPress est dans la plage vulnérable ?
Connectez-vous à votre tableau de bord WordPress et relevez le numéro de version affiché dans Dashboard → Updates. Comparez-le au tableau des versions : si vous êtes entre 6.9.0 et 6.9.4, la version corrigée est 6.9.5. Entre 7.0.0 et 7.0.1, la version corrigée est 7.0.2. Sur la branche 6.8.x, la limite est 6.8.6. La vérification doit porter sur la version exacte, pas sur un indicateur générique « à jour ».
Que faire si je ne peux pas mettre à jour immédiatement ?
En attente du patch, plusieurs mesures réduisent l’exposition. Bloquez les requêtes anormales vers /wp-json/batch/v1 via votre WAF ou votre hébergeur. Surveillez les logs d’accès pour des patterns inhabituels sur ce endpoint. Assurez-vous d’avoir une sauvegarde récente et testée. Vérifiez la liste des comptes administrateurs pour détecter toute création suspecte. Ces mesures ne remplacent pas la mise à jour, elles réduisent la fenêtre d’exposition en attendant.
Pourquoi WordPress a-t-il activé des mises à jour forcées pour cette faille ?
Les mises à jour automatiques forcées sont un mécanisme rare dans WordPress, déclenché uniquement quand l’équipe core juge le risque trop élevé pour le laisser à la discrétion des administrateurs. En juillet 2026, la gravité de la chaîne wp2shell — exécution de code à distance sans authentification, exploitation active confirmée par la CISA — a justifié cette décision. C’est un signal fort : si WordPress dépasse le cadre habituel des mises à jour optionnelles, c’est que la menace est réelle et immédiate.
