WordPress fait tourner plus de 43 % des sites web dans le monde. Cette popularité en fait la cible privilégiée des attaquants, et l’été 2026 vient de le rappeler avec une série de correctifs de sécurité particulièrement dense autour de la nouvelle version majeure, WordPress 7.
wp2shell : failles wordpress 2026 qui a secoué l’écosystème en juillet dernier
Le 17 juillet 2026, WordPress a publié en urgence la version 7.0.2 pour corriger deux vulnérabilités combinables : une confusion de route dans le point de terminaison batch de l’API REST, associée à une injection SQL dans WP_Query (CVE-2026-60137), et une faille permettant de contourner la politique de sécurité (CVE-2026-63030). Combinées, elles permettaient à un attaquant non authentifié d’exécuter du code arbitraire à distance — le scénario le plus grave qui existe pour un site WordPress. La faille, baptisée « wp2shell » par les chercheurs qui l’ont découverte, touchait les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1.
Le CERT-FR a publié une alerte dès le 20 juillet (CERTFR-2026-ALE-007), signalant l’existence d’une preuve de concept publique et anticipant des tentatives d’exploitation en masse. Quelques jours plus tard, la CISA américaine a confirmé l’exploitation active en ajoutant les deux failles à son catalogue KEV (Known Exploited Vulnerabilities). Étant donné la gravité, WordPress.org a même déclenché des mises à jour automatiques forcées pour les sites concernés dont l’auto-update était activé.
Les correctifs ne se sont pas arrêtés là
Le 6 août 2026, WordPress 7.0.3 a corrigé 12 vulnérabilités supplémentaires : une faille XSS pré-authentification pouvant mener à une exécution de code, plusieurs XSS stockés, une escalade de privilèges sur les installations multisite, des fuites d’information et une faille SSRF (server-side request forgery). Le 12 août, WordPress 7.0.4 est venue corriger encore une faille supplémentaire. En moins d’un mois, ce sont donc trois versions de sécurité distinctes qui se sont succédées.
Ce rythme n’est pas anormal ni inquiétant en soi : c’est le signe d’un projet activement maintenu et d’une communauté de recherche en sécurité très active. Ce qui est en revanche révélateur, c’est l’écart entre les sites qui appliquent ces correctifs dans les heures qui suivent, et ceux qui restent exposés pendant des semaines.
Pourquoi rester à jour ne suffit toujours pas
Les statistiques du secteur sont régulièrement rappelées par les équipes de sécurité : environ 78 % des sites WordPress piratés tournaient sur une version obsolète au moment de l’incident. Mettre à jour reste donc, de très loin, la mesure la plus efficace. Mais entre la divulgation d’une faille et son exploitation active à grande échelle, il peut s’écouler quelques heures à peine — c’est précisément ce qui s’est passé avec wp2shell. Un site avec les mises à jour automatiques désactivées, ou hébergé sur un environnement où elles ne se déclenchent pas correctement, reste vulnérable pendant toute cette fenêtre.
C’est là qu’un pare-feu applicatif web (WAF) et une surveillance active des logs prennent tout leur sens : ils permettent de bloquer une tentative d’exploitation même avant que la mise à jour officielle ne soit appliquée sur votre installation.
Ce que WordPress 7 change côté sécurité
Indépendamment de ces correctifs d’urgence, WordPress 7 intègre nativement des protections qui nécessitaient auparavant une extension tierce : l’authentification à deux facteurs fait désormais partie du cœur du logiciel, activable par rôle depuis les réglages. La version impose également PHP 7.4 comme minimum technique, avec PHP 8.3 recommandé pour bénéficier des meilleures performances et corrections de sécurité du langage lui-même.
Autre nouveauté plus technique : l’Abilities API, qui standardise la manière dont les plugins, thèmes et outils d’intelligence artificielle exposent et contrôlent leurs fonctionnalités sur un site. Avec la multiplication des intégrations IA dans l’écosystème WordPress, cette API vise à encadrer une nouvelle catégorie de risque émergente : la manipulation des instructions données à une IA pour lui faire exécuter des actions non autorisées sur le site.
Ce qu’il faut retenir
Si votre site tourne encore sur une version antérieure à 7.0.4, ou si vous n’êtes pas certain que les mises à jour automatiques fonctionnent réellement sur votre installation, c’est le moment de vérifier — pas d’attendre le prochain bulletin d’urgence. Un audit de sécurité permet de faire le point rapidement sur l’exposition réelle de votre site.
