Failles WordPress trouvées par l’IA : pourquoi vous avez 24 h pour mettre à jour

Vous avez mis à jour votre WordPress le 22 septembre ? Et si oui, à quelle heure ? Ce jour-là, WordPress publiait 7.1.2 pour corriger une faille critique. Patchstack bloquait les premières tentatives d’attaque le jour même, et à 15 h 34 UTC, quelqu’un essayait déjà d’écrire un fichier sur un serveur.

Deux mois plus tôt, wp2shell livrait un site WordPress à n’importe quel visiteur anonyme, sans compte ni extension vulnérable. Celle-là, un modèle d’IA piloté par un chercheur de Searchlight Cyber l’a trouvée en un peu plus de 10 heures et pour environ 25 dollars de calcul.

Le délai entre un correctif et la première attaque se compte désormais en heures. Pas en semaines. Et une mise à jour "automatique" ne passe pas toujours : j’ai vu le cas…

Deux failles critiques du cœur en deux mois : ce qui s’est passé en 2026

Le cœur de WordPress n’a pas l’habitude de ce rythme. Selon Patchstack, 2025 n’avait compté que 6 failles dans le cœur, toutes de faible priorité. Entre le 17 juillet et le 22 septembre 2026, WordPress a publié cinq versions de sécurité, dont deux pour des failles critiques exploitables sans compte.

Date (2026)	Version	Ce qui est corrigé	Signalé par (extrait)	Mise à jour forcée
10 mars	6.9.2	10 failles de sécurité	Plusieurs chercheurs	Non annoncée
10 mars	6.9.3	Régression de 6.9.2 : page blanche sur certains thèmes	Des utilisateurs	Non annoncée
11 mars	6.9.4	Correctifs de 6.9.2 incomplètement appliqués	Équipe de sécurité de WordPress ; Thomas Kräftner	Non annoncée
17 juillet	7.0.2, 6.9.5, 6.8.6	wp2shell : exécution de code sans compte	Adam Kues (Searchlight Cyber) ; TF1T, dtro et haongo	Oui
6 août	7.0.3	12 failles, dont une injection de script avant connexion pouvant mener à l’exécution de PHP	pwn.ai ; Anthropic (injection CSS)	Non annoncée
12 août	7.0.4	Exécution de code depuis un compte Auteur, avec Imagick et Ghostscript	pwn.ai	Non annoncée
17 septembre	7.1.1	11 correctifs de sécurité	Anthropic (2) ; Paulos Yibelo et pwn.ai (1)	Non annoncée
22 septembre	7.1.2 et 24 rétroportages	CVE-2026-87902 : inclusion de fichier, exécution de code sous conditions	Robert Ressl	Non annoncée

wp2shell, 17 juillet 2026 : une exécution de code sans authentification, et des mises à jour forcées

Vendredi 17 juillet, 18 h 45 UTC. WordPress publie 7.0.2, 6.9.5 et 6.8.6 et, vu la gravité, active les mises à jour forcées pour les sites concernés.

La chaîne associe une injection SQL, CVE-2026-60137 (le CVE est l’identifiant public d’une faille), via le paramètre author__not_in de WP_Query, et une confusion de route dans le point d’accès batch de l’API REST, CVE-2026-63030. Au bout : un compte administrateur, puis l’exécution de code.

La chaîne est devenue exploitable sans compte avec WordPress 6.9, en décembre 2025 (l’injection SQL seule existait depuis 6.8, en avril 2025) : Wordfence note qu’une recherche assistée par IA a découvert la faille deux versions du cœur seulement après son introduction.

Le CERT-FR alerte le 20 juillet ("preuve de concept publique", "tentatives d’exploitations en masse" attendues), Cybermalveillance.gouv.fr le 23. La CISA inscrit les deux failles le 21 à son catalogue KEV, celui des failles exploitées en conditions réelles.

CVE-2026-87902, 22 septembre 2026 : 7.1.2 et 24 rétroportages jusqu’à 4.7

Mardi 22 septembre, rebelote. WordPress 7.1.2 corrige une faille signalée par Robert Ressl : un attaquant sans compte peut, sous conditions, faire inclure un fichier PHP situé hors des dossiers du thème actif, jusqu’à l’exécution de code. WordPress la note 9,2 sur 10 (score CVSS 4.0), Wordfence 8,1 (CVSS 3.1). Même faille, deux thermomètres.

Il faut un thème actif avec un dossier de premier niveau commençant par page-, comme page-templates dans Twenty Twelve, Twenty Fourteen, Neve, Hestia ou Sydney. Il faut aussi, sur le serveur, un fichier PHP exploitable : typiquement pearcmd.php, avec register_argc_argv activé. C’est le réglage par défaut des images Docker officielles de PHP et de cPanel avant PHP 8.5.

Rétroporté jusqu’à 4.7, le correctif existe en vingt-quatre versions en plus de 7.1.2. Et contrairement à juillet, WordPress n’annonce aucune mise à jour forcée : c’est une mineure classique, qui passe par le mécanisme automatique habituel… quand il fonctionne.

Entre les deux : 7.0.3, 7.0.4 et 7.1.1, et des découvreurs qui ont changé

Entre ces deux alertes, d’autres versions de sécurité sont sorties. 7.0.3 corrige une injection de script sur l’écran de connexion, exploitable avant toute connexion, signalée par pwn.ai. Pour 7.0.4, c’est encore pwn.ai. Et 7.1.1 crédite Anthropic, l’éditeur de Claude, pour deux failles qui exigent un compte.

pwn.ai se présente comme une plateforme de tests d’intrusion autonome : des agents d’IA qui cartographient une application, enchaînent les bogues et livrent un exploit fonctionnel.

En août et en septembre, pwn.ai ou Anthropic figurent dans les crédits de trois versions de sécurité du cœur sur quatre.

Combien de temps entre un correctif et la première attaque ?

Le délai entre la publication d’un correctif WordPress et la première tentative d’attaque se mesure en heures. En 2026, Wordfence a observé les premières sondes contre wp2shell 4 h 43 après la note de version, et Patchstack a bloqué les premières tentatives contre CVE-2026-87902 le jour même de la sortie de 7.1.2.

Étape	wp2shell (vendredi 17/07/2026)	CVE-2026-87902 (mardi 22/09/2026)
Correctif public	Note de version à 18 h 45 UTC	Commit du correctif à 12 h 04 UTC, avis de sécurité à 13 h 57, note de version à 14 h 01
Pare-feu déployé	Cloudflare à 17 h 03 UTC, prévenu à l’avance ; Wordfence payant le jour même	Patchstack et Wordfence payant le jour même
Première tentative mesurée	23 h 29 UTC, premières sondes ; 23 h 42, première injection SQL (Wordfence)	11 h 49 UTC selon Patchstack
Passage à l’échelle	Exploitation massive dès le 18/07 ; preuves de concept publiques les 18 et 19/07	15 h 34 UTC, première écriture de fichier tentée ; le 23/09, modèle Nuclei public
Catalogue KEV de la CISA	21/07	25/09

D’où vient le délai de 24 heures

Patchstack le mesure à grande échelle : selon son rapport 2026, les attaquants exploitent environ la moitié des failles à fort impact en 24 heures, et la médiane pondérée par l’intensité des attaques tombe à 5 heures. Attention, il s’agit des failles les plus attaquées. Le détail est dans les autres chiffres du rapport Patchstack 2026.

Les 24 heures du titre sont donc un plafond, pas une marge : un délai de correction à ne pas dépasser, pendant lequel les attaques ont souvent déjà commencé. Aucune règle de WordPress ne le fixe : Patchstack juge critiques les 24 premières heures après la publication d’une faille. Sur wp2shell, les premières sondes sont même arrivées moins de 5 heures après la note de version.

Pourquoi si vite ? Parce qu’un correctif est une carte au trésor. La documentation de WordPress l’écrit : quand une version corrige une faille, l’information pour l’exploiter est presque certainement publique. Il suffit de comparer le code avant et après (le diff). Sur CVE-2026-87902, Patchstack a vu des charges reprenant exactement l’encodage que le correctif neutralise.

Comment une IA a-t-elle trouvé wp2shell en 10 heures pour 25 dollars ?

L’histoire, racontée par Adam Kues (Searchlight Cyber) dans un billet du 20 juillet, part d’un prompt publié par OpenAI, celui grâce auquel son modèle était venu à bout d’une conjecture mathématique célèbre.

Le chercheur l’adapte et le pointe sur WordPress : trouver, par la seule analyse du code, une chaîne qui mène d’un visiteur anonyme à l’exécution de code, avec jusqu’à 4 agents et au moins 6 heures de recherche.

À son retour, le modèle (GPT5.6 Sol Ultra) annonce une injection SQL sans authentification. Adam Kues n’y croit pas : WordPress est, écrit-il, l’une des cibles les plus durcies de tous les temps. Il installe un WordPress de test et demande au modèle d’en extraire l’adresse e-mail de l’administrateur… qui s’affiche en quelques minutes.

Environ 4 heures plus tard, le modèle livre la suite : appel batch récursif, cache détourné pour endosser le rôle d’administrateur, faux article qui relance la requête via le hook parse_request. Au bout, un compte administrateur. Le tout pour la moitié du quota hebdomadaire d’un abonnement à 200 dollars (environ 25 dollars), en un peu plus de 10 heures.

Je peux affirmer en toute confiance qu’aucun chercheur en sécurité n’aurait pu trouver et achever cette chaîne d’exploitation en 10 heures sans IA.

Adam Kues, Searchlight Cyber, 20 juillet 2026 (ma traduction)

Un humain reste dans la boucle : il choisit la cible, écrit la consigne et passe une journée à comprendre la chaîne avant d’écrire à WordPress.

De Wordfence à Anthropic, la recherche de failles passe à l’IA

wp2shell n’a rien d’isolé. Chez Wordfence, la part des rapports de failles assistés par IA est passée de 16 % à environ 66 % entre fin 2025 et avril 2026 (chiffres déclarés), et son agent PRISM revendiquait plus de 300 failles en août.

Son outil Argus a trouvé et prouvé en deux heures environ une exécution de code sans authentification dans le thème Avada, vendu à plus d’un million d’exemplaires, en enchaînant six faiblesses (sous condition d’un certain contenu créé par un administrateur).

Chez Sucuri, un lycéen, Luke Herbrandson, a confirmé seize failles d’extensions avec Claude Opus 4.8, en notant que Claude décrivait parfois des contrôles de sécurité absents du code.

Et puis Anthropic. En mai, son programme Project Glasswing annonçait plus de 10 000 failles graves ou critiques trouvées avec une cinquantaine de partenaires. Le constat qu’en tire Anthropic me paraît le plus important de ce dossier : les progrès en sécurité ne sont plus limités par la vitesse à laquelle on trouve les failles, mais par celle à laquelle on les vérifie et on les corrige.

En moyenne, il faut deux semaines pour corriger une faille grave ou critique trouvée par son modèle Mythos Preview.

L’IA travaille aussi pour les attaquants, mais pas comme on le croit

On imagine volontiers des pirates qui demandent à une IA de trouver des failles inédites. Les traces de septembre sont plus terre à terre : sur CVE-2026-87902, selon Patchstack, les premiers attaquants travaillaient à partir du diff, donc du correctif lui-même.

Le lendemain, deux signatures apparaissent dans le trafic : cve-2026-87902-poc/1.0 et nuclei-cve-2026-87902/1.0. Nuclei est un scanner de vulnérabilités libre qui fonctionne avec des modèles partagés : pour Patchstack, un modèle nommé signifie que n’importe qui peut lancer l’attaque sur une liste de sites.

Wordfence rappelle que les attaquants ont accès aux mêmes outils : les priver des modèles capables en cybersécurité leur laisse de nouveaux prompts et des modèles à poids ouverts sans garde-fous. Et Anthropic prévoyait en juin que, d’ici 6 à 12 mois, beaucoup d’autres entreprises d’IA disposeraient de modèles de la classe de Mythos, et pourraient les publier sans protections contre les abus.

Une faille trouvée par une IA est-elle plus dangereuse ?

Une IA réellement pilotée, avec des garde-fous, ne me fait pas peur pour un WordPress : certaines extensions sont bien plus dangereuses qu’elle. Et je ne crois pas au scénario catastrophe.

Les chiffres vont dans ce sens. Sur 1 061 failles attribuées à une découverte assistée par IA, VulnCheck n’en compte que 14 exploitées dans la nature, soit 1,3 %, à peu près le taux observé pour l’ensemble des failles. Une faille trouvée par une IA n’est pas plus dangereuse qu’une autre ; il y en a simplement davantage.

Et après wp2shell, que Wordfence qualifie de première exécution de code critique sans authentification dans le cœur depuis près de dix ans, l’éditeur n’a pas vu de hausse des sites compromis dans les demandes d’aide qu’il reçoit, malgré plus de 11 millions de tentatives bloquées chez ses seuls clients payants.

Il y voit l’effet d’une découverte précoce grâce à l’IA, de règles de pare-feu coordonnées avec les hébergeurs et des mises à jour forcées. Revers de la médaille, Patchstack et Anthropic décrivent une hausse des rapports de failles bâclés générés par IA, et des mainteneurs ont demandé à Anthropic de ralentir ses signalements, faute de temps pour écrire les correctifs.

Les mises à jour automatiques de WordPress vous protègent-elles vraiment ?

Oui, à condition qu’elles tournent. Depuis WordPress 3.7 (2013), les versions mineures, porteuses des correctifs de sécurité, s’installent seules sur la plupart des sites. Depuis 5.5, l’automatique s’active extension par extension ; depuis 5.6, les nouvelles installations reçoivent aussi les versions majeures.

L’équipe de sécurité de WordPress.org peut en plus forcer une mise à jour dans des cas particuliers, pour wp2shell par exemple. Et à grande échelle, ça marche : en mai, 46 % des sites étaient passés à 7.0 en sept jours, selon WordPress.org.

Sur un site donné, rien ne le garantit. Je l’ai vu sur une boutique WooCommerce cliente dont j’assure la maintenance. L’audit de sécurité d’avril relève le réglage : WP_AUTO_UPDATE_CORE à false, "mises à jour contrôlées manuellement". Le cron interne de WordPress, qui déclenche ses tâches planifiées, est désactivé côté serveur : elles passent par WP-CLI, l’outil de WordPress en ligne de commande.

Le 17 juillet, la boutique tourne en 6.9.4, en pleine plage vulnérable, et la mise à jour forcée de wp2shell ne passe pas. Elle est appliquée à la main le lendemain, en 6.9.5 : une demi-heure de travail.

Mais le contrôle manuel laisse filer la suite. Le 22 septembre, lors de la vague de mises à jour, le constat tombe : les correctifs 6.9.6 à 6.9.8 n’avaient jamais été appliqués, la constante valant toujours false. Elle passe à 'minor' le jour même, ce qui laisse passer les versions mineures.

Ce blocage est silencieux. Avec cette constante à false, WordPress ne tente rien, donc n’échoue sur rien. L’écran Santé du site signale pourtant que ce réglage bloque les versions de sécurité et de maintenance. Encore faut-il l’ouvrir…

Les réglages qui coupent l’automatique, et le risque inverse

D’après le code et la documentation de WordPress, ces réglages bloquent une mise à jour automatique sans bruit :

• WP_AUTO_UPDATE_CORE à false : mineures, majeures et développement désactivées ;
• AUTOMATIC_UPDATER_DISABLED à true, ou le filtre du même nom : tout est coupé ;
• DISABLE_WP_CRON à true sans tâche planifiée côté serveur, alors que l’automatique repose sur WP-Cron ;
• un dossier .git, .svn, .hg ou .bzr dans le répertoire de WordPress ou un parent, sauf filtre automatic_updates_is_vcs_checkout ;
• des fichiers non inscriptibles, ou des identifiants FTP exigés pour écrire ;
• un échec critique lors d’une mise à jour automatique précédente, qui désactive les suivantes.

Reste le risque inverse : une mise à jour automatique installe ce que l’éditeur publie, y compris le pire.

Le 28 juillet, PRISM a repéré une porte dérobée dans cette extension vidéo, moins de deux heures après l’injection du code : un jeton écrit en dur donnait un accès administrateur. WordPress.org l’a fermée et confirmé n’avoir, cette fois, pas distribué la version piégée. Et en mars, 6.9.2 a provoqué des pages blanches sur certains thèmes, corrigées par 6.9.3 le jour même.

Malgré ça, ma règle est de laisser les mises à jour de sécurité natives actives. Pour la marche à suivre, voyez la procédure complète pour mettre à jour WordPress. Et si vous tenez à couper l’automatique, le guide pour désactiver les mises à jour automatiques détaille les réglages : relisez juste cette section avant.

Pourquoi 7.0.6 est-elle protégée alors que 7.1.1 ne l’est pas ?

Parce que WordPress corrige plusieurs branches en parallèle. Le 22 septembre, le correctif de CVE-2026-87902 est sorti en 7.1.2, mais aussi en 7.0.6, 6.9.9, 6.8.10 et ainsi de suite jusqu’à 4.7.37. Une version 7.0.6 contient donc le correctif, alors qu’elle est numériquement inférieure à 7.1.1, qui ne le contient pas.

Vous lirez ici et là que "si votre version est inférieure à 7.1.2, votre site est vulnérable". C’est faux ! Wordfence le précise lui-même : les rétroportages du 22 septembre sont corrigés alors que leur numéro est plus petit que 7.1.1.

Et ça concerne du monde… Au 29 septembre, selon les statistiques de WordPress.org, 59 % des sites tournent sur la branche 7.1, les autres en 7.0 (10,4 %), 6.9 (7,4 %), 6.8 (5,7 %) ou plus ancien. Pour environ 40 % des sites, le bon numéro n’est donc pas 7.1.2.

Branche	wp2shell corrigée à partir de	CVE-2026-87902 corrigée à partir de
7.1	Non concernée (corrigée dès la 7.1 bêta 2)	7.1.2
7.0	7.0.2	7.0.6
6.9	6.9.5	6.9.9
6.8	6.8.6 (injection SQL seule)	6.8.10
6.7 et 6.6	Non concernées	6.7.9, 6.6.9
6.5 à 6.0	Non concernées	6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16
5.9 à 5.0	Non concernées	5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29
4.9 à 4.7	Non concernées	4.9.33, 4.8.32, 4.7.37

Comment vérifier en cinq minutes que votre site est bien corrigé ?

Pas besoin d’être développeur pour le plus gros. Le menu Tableau de bord > Mises à jour affiche la version installée : comparez-la au tableau ci-dessus pour ces deux failles, puis vérifiez que c’est la dernière version de votre branche.

Le menu Outils > Santé du site contient deux tests utiles. L’un vérifie que les mises à jour en arrière-plan fonctionnent, et nomme ce qui les bloque (WP_AUTO_UPDATE_CORE à false, dossier .git, fichiers non inscriptibles). L’autre vérifie que les tâches planifiées tournent à l’heure.

Avec un accès SSH (une connexion sécurisée à votre serveur) et WP-CLI, voici les commandes que je vous conseille, dans cet ordre :

# Version installée (à comparer au tableau de votre branche)
wp core version --extra

# Une version mineure plus récente existe-t-elle sur votre branche ?
wp core check-update --minor

# Si oui : n'installer que la mise à jour mineure de la branche
wp core update --minor

# Les fichiers du cœur sont-ils identiques à ceux de WordPress.org ?
wp core verify-checksums

# Les mises à jour automatiques sont-elles bloquées dans wp-config.php ?
# (une erreur "not defined" = constante absente, comportement par défaut)
wp config get WP_AUTO_UPDATE_CORE

# WP-Cron fonctionne-t-il ?
wp cron test

wp core verify-checksums compare vos fichiers du cœur aux sommes de contrôle de WordPress.org ; elle figure dans les contrôles de fin de mise à jour de la boutique dont je parlais. wp cron test, lui, échoue si DISABLE_WP_CRON est actif : une vraie tâche planifiée doit alors prendre le relais.

Les traces d’intrusion à chercher après la mise à jour

Une mise à jour ne nettoie pas un site déjà piraté. Si votre site est resté exposé, cherchez les comptes administrateurs inconnus (ceux que créaient les attaques wp2shell), les fichiers PHP récents et, pour CVE-2026-87902, les .php inattendus dans /tmp ou /var/tmp. Voyez aussi les 20 indices d’un WordPress à risque ou déjà piraté.

Un nettoyage peut aussi oublier des choses. Sur la boutique, piratée en janvier 2026 et nettoyée par un prestataire antérieur, un audit a trouvé en juillet 400 liens cachés vers des sites de jeux d’argent, dormants dans le réglage d’une extension désinstallée.

Les trois sauvegardes de base du serveur les contenaient toutes : une restauration les aurait réinjectés. Purge le jour même. Si vous en êtes là, suivez la marche à suivre quand un WordPress a été piraté jusqu’au bout.

Un pare-feu gratuit vous couvre-t-il pendant les 24 premières heures ?

Rarement, et c’est un point qu’on oublie trop souvent. Prenez Wordfence.

Son pare-feu gratuit reçoit les règles et les signatures de logiciels malveillants 30 jours après les clients payants, comme l’indique sa fiche WordPress.org. Chaque billet de l’éditeur en donne la date exacte :

Faille	Correctif de l’éditeur	Wordfence payant	Wordfence gratuit
wp2shell (cœur)	17/07/2026	17/07/2026	16/08/2026
Avada et Fusion Builder (thème commercial)	25/08/2026	30/07/2026	29/08/2026
CVE-2026-87902 (cœur)	22/09/2026	22/09/2026	22/10/2026

Pendant la fenêtre qui compte, l’extension gratuite ne reçoit donc pas de règle dédiée à une faille nouvelle.

Patchstack fonctionne à l’inverse : la version gratuite prévient (jusqu’à 48 heures à l’avance pour les failles trouvées par sa communauté) et peut mettre à jour un composant vulnérable. La protection automatique est payante : plus de 12 000 correctifs virtuels, ces règles qui bloquent une faille précise sans toucher au code du site.

Cloudflare et les parades d’urgence

Cloudflare a fait mieux sur wp2shell : prévenu par l’équipe de sécurité de WordPress, il a déployé ses règles le 17 juillet à 17 h 03 UTC pour tous ses clients, offre gratuite comprise, si le trafic passe par son pare-feu applicatif. Rien ne garantit que ce sera le cas à chaque faille.

Pour le reste de l’hygiène (comptes, droits, sauvegardes), je vous renvoie à ma checklist complète pour sécuriser WordPress.

Ce qu’un contrat de maintenance doit garantir : des délais chiffrés

"Nous appliquons les mises à jour régulièrement." Ce genre de phrase ne vous protège de rien face à une fenêtre de quelques heures.

J’ai détaillé ailleurs les clauses d’un contrat de maintenance WordPress sérieux. Ici, une seule compte : le délai de correctif de sécurité, écrit pour être vérifiable. Les valeurs entre crochets se négocient.

1. Est "critique" toute faille touchant une version installée qui remplit au moins un de ces critères : exploitable sans compte, déjà exploitée selon un éditeur de sécurité reconnu, ou inscrite au catalogue KEV de la CISA.
2. Pour une faille critique, le correctif ou une mesure de protection (règle de pare-feu, fonction désactivée) est appliqué dans les [24] heures suivant la publication de l’avis de sécurité ; le contrat dit ce qui prend le relais hors jours ouvrés.
3. Hors faille critique, le correctif suit le cycle prévu, après test en préproduction.
4. Après chaque intervention de sécurité, le rapport donne la version installée sur chaque site et le résultat du contrôle d’intégrité du cœur.
5. Les avis de sécurité sont suivis chaque jour, sur l’inventaire réel des extensions et thèmes.
6. La liste des installations couvertes, préproductions comprises, est annexée au contrat et tenue à jour.
7. Un report n’est admis que pour une faille qui exige un compte, par décision écrite et motivée, avec une mesure d’atténuation.

Pourquoi parler des jours non ouvrés ? Parce que wp2shell est sortie un vendredi soir et que l’exploitation massive a commencé le samedi. Sur la boutique dont je parlais, la correction manuelle de wp2shell s’est faite le lendemain de sa publication, un samedi. Demandez à votre prestataire ce qui prend le relais hors jours ouvrés : mise à jour automatique native, règle de pare-feu, astreinte.

Reporter une mise à jour de sécurité : à quelles conditions

La clause sur le report, la dernière de la liste, vient d’un cas réel, sur la même boutique cliente, avec l’extension qui construit ses pages.

Sa version d’Elementor, 4.0.3, était exposée à CVE-2026-6127 (injection de script persistante notée 6,4 sur 10) et à CVE-2026-49782, qui exigent toutes deux un compte Contributeur. Repérées par la veille mensuelle. On a commencé par vérifier qui pouvait obtenir ce rôle : l’inscription publique donnait le rôle client, pas Contributeur. Impossible, donc, d’exploiter ces failles en s’inscrivant.

La boutique était en pleine période de soldes, mises à jour gelées. En attendant, on a masqué le numéro de version d’Elementor, affiché en clair dans les pages, pour ne plus le livrer aux attaquants (ce qui ne corrige aucune des deux failles). La mise à jour est passée après les soldes, en préproduction puis en production.

Cet arbitrage de risque reposait sur ce prérequis, vérifié sur la boutique, et il était documenté. Appliqué à wp2shell, il aurait été une faute : tout tient dans le prérequis, un compte d’un côté, rien du tout de l’autre. Je vous invite donc à vérifier les failles de vos extensions avant de paniquer, ou de vous endormir.

Si vous préférez déléguer, mes forfaits de maintenance démarrent à 590 € HT par mois, avec des délais d’intervention écrits au contrat et le mois suivant offert s’ils ne sont pas tenus sur un incident critique. Ces délais s’entendent en heures ouvrées. Hors jours ouvrés, ce sont les mises à jour automatiques de sécurité du cœur de WordPress qui prennent le relais, et je les laisse actives. Pour une extension, le délai court en heures ouvrées, sauf astreinte prévue au contrat : je la propose sur demande avec le forfait Premium.

Ma politique de mise à jour, site par site

Chez moi, tout part d’une veille technique pilotée par l’IA : elle me signale toutes les failles de sécurité qui touchent les sites que j’administre ou dont j’assure la maintenance. Je ne suis donc pas pollué par celles qui ne me concernent pas.

L’outil Veille Sécurité, gratuit pour les abonnés, suit la même logique : il compare chaque jour extensions et thème à la base WPVulnerability.net et n’écrit qu’en cas de faille (voir comment fonctionne cette veille des failles de vos extensions).

Aujourd’hui, les mises à jour automatiques de sécurité, je les applique dans tous les cas de figure. C’est natif à WordPress, donc de ce côté-là, je n’ai pas trop de soucis. Sur le WordPress qui fait tourner ce site, 7.1.2 s’est installée toute seule le 22 septembre à 17 h 05.

La boutique dont je parlais montre que ça ne va pas de soi : un seul réglage suffisait à couper cette protection, sans bruit. Depuis le 22 septembre, elle suit la même règle.

Le reste passe par une préproduction, où quasiment tout est automatisé par l’IA : c’est testé, tout est vérifié, et une fois que tout est OK, la mise à jour part en production.

Le délai que je m’impose comme éditeur

Je suis aussi de l’autre côté de la barrière, celui de l’éditeur d’extension. Je développe Login Armor, une extension de sécurité gratuite publiée sur WordPress.org sous mon nom.

Elle blinde la page de connexion : adresse masquée, détection de la force brute, journal d’activité (détails dans ma présentation de Login Armor contre les attaques par force brute). Je n’ai jamais reçu de rapport de faille sur Login Armor. Mais si j’en recevais un, il serait corrigé dans les 24 heures.

Et l’IA dans tout ça ? Elle a trouvé wp2shell, elle trie ma veille et elle déroule mes mises à jour. Mais reporter ou non un correctif sensible reste une décision humaine : le report d’Elementor en est un exemple.

Les failles WordPress trouvées par l’IA ne changent pas la nature du risque, elles changent l’horloge. Face à un délai qui se compte en heures, la seule défense qui tienne est une mise à jour de sécurité qui passe toute seule… et que quelqu’un vérifie le jour même.

Questions fréquentes

WordPress est-il fiable en 2026 ?

Le cœur, oui, avec une réserve. Selon Wordfence, wp2shell était sa première exécution de code critique sans authentification depuis près de dix ans, et Patchstack n’y comptait que 6 failles mineures en 2025. Mais une deuxième faille critique a suivi.

Faut-il activer les mises à jour automatiques des extensions ?

Environ la moitié des failles à fort impact étant exploitées en 24 heures (Patchstack), l’automatique a de solides arguments, malgré le risque de casse. Sur une boutique WooCommerce cliente que je maintiens, les extensions passent pourtant par une préproduction, et les mises à jour de sécurité natives du cœur y sont de nouveau actives depuis le 22 septembre.

Mon site est en 7.0.6 : est-il vulnérable ?

Pas à CVE-2026-87902 ni à wp2shell : 7.0.6 corrige la faille de septembre sur la branche 7.0 et contient le correctif de 7.0.2. En revanche, elle n’a pas les correctifs du 6 octobre : installez au moins 7.0.7, qui les rétroporte. Seule la dernière version étant maintenue, prévoyez tout de même le passage à 7.1.

Que faire si je ne peux pas mettre à jour tout de suite ?

Activez une règle de pare-feu dédiée si votre offre en fournit une, et appliquez les parades publiées (blocage de /wp-json/batch/v1 pour wp2shell, filtrage du paramètre pagename pour CVE-2026-87902). La mise à jour reste la seule correction.

L’IA rend-elle WordPress moins sûr ?

Elle raccourcit les délais des deux côtés. Mais VulnCheck ne compte que 1,3 % de failles exploitées parmi celles découvertes avec une IA, et Wordfence n’a pas vu de hausse des sites compromis après wp2shell. Pour moi, une IA pilotée avec des garde-fous reste moins dangereuse que certaines extensions.

Sources

Toutes lues le 29 septembre 2026 ; citations anglaises traduites par mes soins.

• WordPress.org : notes de version 7.0.2, 7.0.3, 7.0.4, 7.1.1, 7.1.2, 7.1.3, 6.9.3 et 6.9.4
• WordPress.org : WP23, WordPress 3.7 et statistiques des versions
• Documentation : Configuring Automatic Background Updates, Plugin and themes auto-updates, Hardening WordPress et commandes WP-CLI
• Code de WordPress : Santé du site, mises à jour automatiques, avis de sécurité et commits
• Searchlight Cyber : annonce de wp2shell et récit de la découverte ; Patchstack : analyse de 7.1.2, premières attaques et rapport 2026
• Wordfence : wp2shell Aftermath, données d’attaque, CVE-2026-87902, IA et recherche, Argus et Avada, manifeste Argus et porte dérobée
• Sucuri, Cloudflare, VulnCheck, Anthropic (bilan de Glasswing et extension du programme), pwn.ai et Nuclei
• CERT-FR, Cybermalveillance.gouv.fr et fiches NVD CVE-2026-60137, CVE-2026-63030 et CVE-2026-87902