Le 2 septembre 2026, WP Tavern publie l’épisode 232 de son podcast Jukebox. L’invité, Aaron D Campbell, a dirigé pendant plusieurs années l’équipe sécurité de WordPress lui-même, avant de passer par la sécurité hébergement chez GoDaddy puis Newfold. Il est aujourd’hui VP Product chez Monarx, éditeur d’outils de détection et de remédiation de malware pour les hébergeurs. Allons voir ce qu’il avait à dire, ensemble !
À quelle vitesse l’exploitation va-t-elle aujourd’hui ?
C’est la suite logique d’un sujet déjà traité ici : le 17 juillet 2026, wp2shell forçait une mise à jour d’urgence du noyau après la découverte d’une faille déjà exploitée. Il manquait alors un chiffre sur la vitesse réelle d’exploitation une fois le correctif publié. C’est précisément ce que comble l’entretien de Campbell.
Campbell observe l’exploitation côté hébergeur, chez Monarx, et selon lui, dans le podcast, le délai s’est réduit à presque rien. « Une fois le correctif publié, quand tout était disponible, le pic d’exploitation que nous avons observé chez Monarx, en surveillance, est arrivé en 30 minutes », a-t-il déclaré. « Honnêtement, même un peu plus vite que ça. » Pour les vulnérabilités qu’il qualifie de majeures, il évalue le délai entre découverte et exploitation à environ cinq heures. Ce sont les chiffres de surveillance propres à Monarx, sur son propre périmètre, pas une étude sectorielle publiée indépendamment : ils décrivent ce qu’observe un éditeur de sécurité hébergeur, pas une règle valable pour tous les sites WordPress.
Plus loin dans l’entretien, Campbell mentionne un rapport d’exploitation qui, une fois imprimé, faisait onze pages : une illustration du nombre d’étapes que chaînent désormais les attaques modernes. Dans ses propres mots, la bataille est passée d’une bataille d’ingéniosité, où un attaquant humain devait enchaîner plusieurs failles avec un vrai savoir-faire, à une bataille de puissance de calcul, où un système IA peut chercher cette même chaîne bien plus vite qu’une personne.
Qu’a construit WordPress.org pour donner du temps aux défenseurs ?
La réponse de WordPress.org est arrivée trois mois plus tôt, le 5 juin 2026 : WordPress.org annonçait Protect the Shire dans un billet officiel signé Matt Mullenweg.
Le mécanisme est un délai, pas un mur : une fois une mise à jour de plugin ou de thème soumise, le fichier lui-même est publié tout de suite sur WordPress.org, mais la notification de mise à jour qui apparaîtrait normalement dans le tableau de bord d’un site est retenue jusqu’à 24 heures. Cette fenêtre existe pour qu’un outil de revue assisté par IA, baptisé Gandalf par WordPress.org, puisse examiner le changement aux côtés de la revue humaine existante, avant qu’il n’atteigne les sites en production, et non après. L’initiative couvre plus de 78 000 plugins et thèmes, sur un répertoire qui compte plus de 400 millions d’installations cumulées et, aux pics, plus de 3 000 commits par jour. Comme le dit l’annonce : « La liberté et la sécurité ne sont pas un jeu à somme nulle. »
Sur le podcast, Campbell évoque ce délai comme « quelque chose de l’ordre de six heures », un chiffre plus rond et plus approximatif que les 24 heures réellement publiées par WordPress.org : c’est ce chiffre officiel qu’il faut retenir, pas celui dit à l’oral en conversation. Protect the Shire est aussi le deuxième chantier IA que WordPress ajoute à son cœur cette année, après les trois briques qui ont rendu le logiciel agentique en mai dernier, même si l’IA y joue la défense plutôt que la fonctionnalité nouvelle.
Notre avis
Rien de tout cela ne fait de WordPress une cible à part. Cela montre plutôt que l’un des plus grands écosystèmes logiciels d’Internet court après le même écart que toutes les plateformes affrontent désormais : le temps entre la publication d’une faille et le moment où un attaquant assisté par IA la trouve. Protect the Shire donne à la revue des heures qu’elle n’avait pas avant, mais ne remplace pas ce qui se passe sur votre propre site.
Le conseil de Campbell, à la fin du podcast, reste d’un bon sens tout simple : activez les mises à jour automatiques partout où un plugin ou un thème le permet, choisissez un hébergeur qui prend la sécurité au sérieux plutôt que le moins cher du marché, et vérifiez régulièrement vos propres identifiants sur un service comme Have I Been Pwned. Activer les mises à jour automatiques est LE changement que Campbell rappelle sans cesse, bien avant tout ce que les défenses de WordPress.org peuvent faire à votre place. Si vous avez déjà suivi la vérification de deux minutes que nous détaillions pour la CVE-2026-32475 d’Elementor Pro, le même réflexe s’applique ici, en attendant que le reste de l’écosystème rattrape des attaquants accélérés par l’IA.
Photos : Towfiqu Barbhuiya/Pexels, cottonbro studio/Pexels, Vanessa Garcia/Pexels.
