L'été 2026 a été brutal pour la sécurité WordPress : une exécution de code à distance dans le cœur (wp2shell), un piratage de la supply chain sur sept extensions, une série de vulnérabilités critiques. Ce que j'en retiens, et le plan que j'applique.
Je maintiens des sites WordPress et WooCommerce pour mes clients, et j'ai passé cet été beaucoup plus de temps que d'habitude à surveiller des flux de vulnérabilités et à pousser des correctifs dans l'urgence. Quand une faille du cœur devient exploitable en masse en quelques heures, il faut parfois intervenir le soir même sur une boutique qui continue d'encaisser des commandes pendant l'opération. Voici ce qui s'est passé, vérifié source par source.
wp2shell, le cœur de WordPress pris en défaut
Le 17 juillet 2026, WordPress publie une mise à jour de sécurité qui corrige deux failles distinctes. Prises séparément, aucune ne donne l'exécution de code. Chaînées, elles offrent une RCE non authentifiée sur un WordPress nu, sans extension, sans compte valide, sans interaction humaine. La chaîne a été baptisée wp2shell.
- CVE-2026-63030, une confusion de routes dans le processeur de lots de l'API REST (
/wp-json/batch/v1), qui permet de faire exécuter une requête sous le mauvais gestionnaire et donc de passer à côté des contrôles d'authentification. - CVE-2026-60137, une injection SQL dans le paramètre
author__not_inde l'endpoint des articles, interpolé directement dans la requête brute lorsqu'il est fourni sous forme de chaîne.
L'injection SQL est en lecture seule, mais elle suffit à forger des données que WordPress lui même va ensuite traiter : des articles et un changeset du customizer qui aboutissent à la création d'un compte administrateur. À partir de là, l'attaquant se connecte et téléverse une extension qui fait office de webshell, ce qui referme la boucle sur la prise de contrôle complète du serveur (Patchstack).
Les versions concernées sont 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 pour la chaîne complète, la branche 6.8 n'étant touchée que par l'injection SQL. Les correctifs sont sortis en 6.8.6, 6.9.5 et 7.0.2, et WordPress a pris la mesure inhabituelle de forcer la mise à jour automatique sur les installations éligibles (Tenable, Rapid7).
Patchstack a observé les premières tentatives d'exploitation réelles environ 90 minutes après la sortie de la 7.0.2, soit trois heures après le commit du correctif : le temps que quelqu'un lise le diff public, en tire un scanner, et le pointe sur tout ce qui bouge. En quelques jours, plus de 65 000 tentatives bloquées depuis plus de 1 500 adresses IP distinctes, réparties de façon très décentralisée. Plusieurs éditeurs ont confirmé une exploitation active dans les trois jours suivant la divulgation, et les deux CVE ont rejoint le catalogue KEV de la CISA le 21 juillet (SecurityWeek, The Hacker News).
Un point que mes clients comprennent rarement du premier coup : mettre à jour ne désinfecte pas. Si le site a été touché avant le correctif, le compte administrateur forgé et le webshell sont toujours là. Il faut vérifier les comptes administrateurs, les extensions récemment ajoutées, les fichiers PHP inattendus dans wp-content/uploads et surtout wp-content/mu-plugins, qui se charge automatiquement sans jamais apparaître dans l'écran des extensions.
# Comptes administrateurs, y compris ceux qu'un filtre tenterait de masquer
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Fichiers PHP là où il ne devrait jamais y en avoir
find wp-content/uploads -name '*.php' -mtime -90
ls -la wp-content/mu-plugins/
Deux répliques dans le cœur, en août
wp2shell n'a pas été un incident isolé. Le 6 août, la version 7.0.3 corrige douze vulnérabilités, dont CVE-2026-64638, surnommée XSS2Shell : un XSS réfléchi pré authentification sur l'écran de connexion, déclenché par une simple tentative de login ratée, qui peut être enchaîné jusqu'à l'exécution de code PHP si un administrateur connecté est visé. Le correctif a été rétroporté sur les branches maintenues (Patchstack).
Le 12 août, la 7.0.4 corrige CVE-2026-65640 (CVSS 8.8), une exécution de code par téléversement d'image sur les serveurs qui branchent ImageMagick sur Ghostscript. Le mécanisme tient en deux lignes : ImageMagick identifie un fichier par son contenu, là où WordPress faisait confiance à l'extension du nom. Un fichier nommé .png contenant du PostScript passait le contrôle, arrivait chez Ghostscript, et y était exécuté comme un programme. Il faut un compte de niveau auteur ou supérieur, ce qui limite la portée, mais le code fautif traînait depuis la version 4.7, soit près de dix ans (SecurityWeek).
Ce rythme s'explique en partie par la recherche assistée par IA, qui produit désormais des chaînes d'exploitation complètes en quelques jours, alors que les délais de correction côté hébergeurs et agences n'ont pas bougé.
L'attaque supply chain BdThemes, l'angle mort
Début août, Wordfence est alerté d'une compromission touchant sept extensions de l'éditeur BdThemes : Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste et Smart Admin Assistant, soit plus de 350 000 installations actives cumulées. WordPress.org a fermé les fiches concernées les 7 et 8 août (The Hacker News, BleepingComputer).
Ce qui rend cette attaque intéressante, c'est que le code source des extensions n'a pas été modifié. Aucun fichier du dépôt officiel n'a bougé. Les attaquants ont obtenu un accès en écriture sur un bucket DigitalOcean Spaces hébergeant un flux JSON promotionnel statique, celui que le composant interne Biggopti va chercher pour afficher des bannières dans l'administration. Une faille d'échappement introduite en mars 2026 sur le paramètre display_id a permis d'injecter du JavaScript dans la réponse de l'API. Le script s'exécutait alors dans le navigateur d'un administrateur connecté, avec ses droits.
La charge utile faisait le travail complet : contact d'un serveur de commande, création de comptes administrateurs masqués des listes d'utilisateurs par manipulation des requêtes, installation d'une fausse extension déposant un webshell PHP, et pose d'une porte dérobée de connexion sans authentification (Infosecurity Magazine).
Le problème, pour qui surveille un parc, c'est que tous les contrôles habituels passaient au vert : l'extension est légitime, elle vient du dépôt officiel, ses fichiers ont la bonne empreinte, sa version est à jour. Le code malveillant arrivait à l'exécution, depuis un service distant appelé par l'extension. Dès qu'une extension rapatrie du contenu tiers dans l'administration, la surface d'attaque déborde donc du code qu'on a installé, ce qui est une raison assez concrète d'en limiter le nombre.
La série noire des extensions
En parallèle, l'été a produit une liste inhabituellement dense de failles critiques exploitables sans authentification. Voici celles que j'ai suivies de près, toutes corrigées à ce jour.
| Composant | CVE | Nature | CVSS | Versions vulnérables | Corrigé dans |
|---|---|---|---|---|---|
| GiveWP | CVE-2026-82222 | Injection d'objet PHP menant à une RCE non authentifiée | 10.0 | ≤ 4.16.7.1 | 4.16.7.2 (27 août) |
| TranslatePress | CVE-2026-19632 | Fuite de la clé de réinitialisation du mot de passe admin | 9.8 | ≤ 3.3.1 | 3.3.2 |
| Avada + Fusion Builder | CVE-2026-18431 | Écriture de fichier arbitraire menant à une RCE | 9.8 | Avada ≤ 7.16, Fusion Builder ≤ 3.16 | 7.16.1 et 3.16.1 |
| Pods | CVE-2026-19598 | Contournement d'autorisation, élévation de privilèges | 9.8 | ≤ 3.3.9 | 3.3.10 |
| Forminator | CVE-2026-15748 | Téléversement de fichier non authentifié | 9.8 | ≤ 1.56.1 | 1.56.2 (31 juillet) |
Deux méritent un mot. GiveWP est le seul 10.0 de la liste : une chaîne de gadgets exploitable sur une installation par défaut, avec un seul formulaire de don publié et une passerelle de paiement active, sans authentification ni action d'un administrateur (Patchstack, Security Affairs).
TranslatePress, utilisé par plus de 400 000 sites, exposait la clé de réinitialisation du mot de passe administrateur en clair à n'importe quel visiteur, via une action AJAX accessible sans connexion, dans la configuration par défaut du plugin (The Hacker News). Forminator, plus de 600 000 installations et environ 300 000 sites potentiellement exposés selon SecurityWeek, permettait le dépôt de fichiers PHP sur les formulaires combinant un champ d'envoi de fichier et un champ de sélection.
Ce que l'été change pour la maintenance
Le chiffre à retenir reste ces 90 minutes entre la publication du correctif 7.0.2 et les premières attaques observées sur des sites réels. Le compte à rebours ne démarre pas à la découverte de la faille par les chercheurs, mais au moment où le correctif devient public et où n'importe qui peut en lire le diff.
Cette accélération n'est pas propre à WordPress. VulnCheck relève que près d'une vulnérabilité exploitée sur quatre (23,4 %) l'est avant ou le jour même de sa divulgation publique, et que le délai médian entre publication d'une CVE et exploitation confirmée est tombé de 120 jours en 2025 à 80 jours sur le premier semestre 2026 (VulnCheck). Sur les failles à fort impact et à cible massive comme WordPress, ce délai se compte en heures.
La mise à jour mensuelle faite à la main ne protège donc plus contre ce type de faille. Un rythme mensuel laisse en moyenne deux semaines de fenêtre ouverte sur quelque chose qui commence à être exploité en une heure et demie.
Le plan d'action que j'applique
Voici l'ordre dans lequel je traite un site ou un parc, en commençant par ce qui rapporte le plus.
- Faire l'inventaire, et le tenir à jour. Version du cœur, liste des extensions et des thèmes avec leur version, liste des comptes administrateurs, pour chaque site. Sans inventaire, vous ne pouvez pas répondre à la seule question qui compte quand une CVE tombe : « est ce que je suis concerné, et sur quels sites ». Cette question doit se traiter en secondes, pas en une matinée de connexions manuelles.
- Laisser les mises à jour automatiques du cœur activées. C'est exactement ce qui a sauvé une grande partie des sites sur wp2shell. Le risque de régression est réel mais très inférieur au risque d'une RCE non authentifiée.
- Mettre à jour vite, mais avec un filet. Une mise à jour rapide n'est tenable que si le retour arrière est immédiat : sauvegarde avant opération, restauration automatique en cas d'erreur fatale. C'est ce qui permet de dire oui le jour même au lieu de reporter « au prochain créneau ».
- Réduire la surface. Chaque extension est une dépendance dont vous héritez des failles, et parfois, comme chez BdThemes, du flux distant qu'elle consomme. Une extension inutilisée mais présente reste exploitable. Supprimez, ne désactivez pas.
- Poser un WAF et compter sur le virtual patching. Entre la divulgation et le correctif éditeur, ou entre le correctif et votre créneau de mise à jour, une règle de pare feu applicative est souvent la seule protection disponible. C'est ce qui a absorbé une partie des 65 000 tentatives wp2shell.
- Appliquer le moindre privilège et auditer les comptes. Pas d'administrateur pour un rédacteur, authentification à deux facteurs sur les comptes à privilèges, et une revue régulière : plusieurs attaques de l'été créent des administrateurs, parfois masqués de la liste des utilisateurs.
- Tester les sauvegardes. Tant qu'on n'en a pas restauré une pour de vrai, on ne sait pas si elle fonctionne. Et une sauvegarde qui contient déjà le webshell ne sert à rien, d'où l'importance de la profondeur de rétention.
- Surveiller les vulnérabilités en continu. Recevoir l'information le jour de la divulgation, pas dans le rapport mensuel.
Ce que ça m'a poussé à construire
Ce dernier point m'a coûté le plus de temps cet été, parce que le faire à la main sur plusieurs sites ne passe pas à l'échelle. J'ai fini par le coder : wp-dashboard, mon outil open source pour superviser un parc de sites WordPress, qui centralise l'inventaire, croise les versions installées avec la veille de vulnérabilités et applique les mises à jour avec retour arrière automatique. C'est ce que j'ai trouvé de mieux pour répondre en quelques minutes à la question « quels sites sont concernés ».
Le reste relève de la maintenance ordinaire, faite sérieusement, ce qui suffit généralement à éviter les trois jours de nettoyage après coup. Sur le versant performance du même travail, voir aussi Optimisation des performances WooCommerce.
Votre site tourne sur une version antérieure à la 7.0.4, ou vous ne savez pas dire quelles extensions sont installées sur votre parc ? Parlons en, je fais l'inventaire et je remets à niveau.