IA et WordPress : pourquoi les attaques arrivent en quelques heures
En août, une préprod WordPress dont je m'occupe s'est fait pirater : des comptes administrateurs créés par injection, mon mot de passe modifié, pendant que le site attendait les retours du client. J'ai raconté l'enquête et ses quatre indices dans un premier article. Celui-ci s'attaque à la question qu'elle m'a laissée : pourquoi tout va si vite.
Sur les sites que je maintiens, je retrouve depuis quelques mois le même ordre de grandeur : une faille est publiée, et environ 48 heures plus tard, les premières tentatives d'exploitation apparaissent dans les logs. Il y a trois ou quatre ans, on comptait plutôt en semaines. C'était logique : il fallait étudier la faille soi-même, puis écrire le code d'attaque à la main, et ça prenait du temps. Mon intuition, c'est qu'une bonne partie de ce travail est aujourd'hui automatisée.
Une intuition de terrain ne suffit pas. Alors j'ai cherché ce que disent les chiffres.
Une cible de choix
WordPress fait tourner 40,2 % de tous les sites web dans le monde (W3Techs, septembre 2026). Pour un attaquant, c'est le meilleur rendement possible : un seul exploit ouvre la porte de millions de sites. Et une bonne partie de ces sites n'est pas à jour. Selon la même source, plus d'un site WordPress sur trois ne tourne même pas sur la version majeure actuelle. Statistiquement, un robot qui teste une faille fraîche sur des milliers de sites est certain d'en trouver qui n'ont pas été corrigés. Ma préprod en faisait partie.
Des correctifs à un rythme inédit
Entre le 6 août et le 22 septembre 2026, WordPress a publié quatre versions de sécurité (WordPress.org) :
| Version | Date | Contenu sécurité |
|---|---|---|
| 7.0.3 | 6 août | plusieurs correctifs |
| 7.0.4 | 12 août | 1 correctif |
| 7.1.1 | 17 septembre | 11 correctifs |
| 7.1.2 | 22 septembre | 1 faille critique |
Quatre en sept semaines, rien que pour le cœur. Et le cœur pèse peu : selon Patchstack, 11 334 vulnérabilités ont été recensées dans l'écosystème WordPress en 2025, contre 7 966 en 2024, soit 42 % de plus. 91 % concernent des plugins (Patchstack, State of WordPress Security in 2026).
Des attaques qui suivent en quelques heures
Quand WordPress publie un correctif, le code d'avant et celui d'après sont publics. Il suffit de comparer les deux pour voir où était la faille. Pour la version 7.1.2, Patchstack a observé les premières tentatives d'exploitation environ 12 heures après la sortie du correctif (Patchstack). Sur les failles les plus exploitées, le même rapport mesure un délai médian de 5 heures avant la première attaque.
Mes 48 heures étaient donc plutôt optimistes.
Mozilla : ce que l'IA trouve dans du code ancien
Depuis février 2026, Mozilla fait analyser le code de Firefox par des modèles d'IA. Au printemps, elle a testé Claude Mythos Preview, un modèle d'Anthropic réservé pour l'instant à quelques éditeurs de logiciels critiques. Résultat : 271 failles trouvées lors d'une seule évaluation, dont 180 jugées graves, toutes corrigées dans Firefox 150. En 2025, Mozilla corrigeait 20 à 30 failles par mois. En avril 2026, elle en a corrigé 423 (Mozilla Hacks).
Le plus frappant, c'est l'âge de certaines failles : un bug de 15 ans dans l'élément <legend>, un autre de 20 ans dans le moteur XSLT. Du code en service depuis deux décennies, passé sous les yeux de générations de développeurs, sans que personne ne voie rien. Un ingénieur sécurité de Mozilla, interrogé par Underscore_, résume l'autre face du problème : sur un logiciel open source, dès qu'un correctif apparaît dans l'historique du code, les attaquants ont à peu près une journée pour en tirer un exploit.
WordPress coche toutes ces cases : open source, plus de vingt ans de code, et des correctifs visibles de tous.
Anthropic : ce que l'IA change pour les attaquants
C'est ici que mon intuition trouve sa confirmation. Dans son rapport de septembre 2026 sur les usages malveillants de ses modèles, Anthropic fait un constat net : l'IA a comblé l'écart de main-d'œuvre et d'outillage qui séparait les opérations soutenues par des États des attaquants isolés. Chercher une faille, écrire l'exploit, le tester, l'adapter à chaque cible : ce travail demandait une équipe de spécialistes. Il est désormais confié à des modèles qui tournent « à la vitesse de la machine et en parallèle ». Le rapport décrit des intrusions bouclées en quelques heures, là où il fallait des semaines (Anthropic, Threat Intelligence Report).
C'est exactement le basculement que je voyais dans mes logs, sans pouvoir l'expliquer.
Le même rapport cite un cas qui touche directement WordPress. Un hacktiviste français s'est servi de Claude pour mettre au point, et déboguer dans la même session, un exploit visant une faille WordPress jusque-là inconnue. Cette faille permettait de créer un compte administrateur sans aucun identifiant. Au moins quatre sites y sont passés, dans une campagne qui visait des partis politiques, des médias et leurs prestataires. Ce n'est pas la faille qui a touché ma préprod, mais le symptôme est le même : des comptes admin qui apparaissent sans que personne ne les ait créés.
Ce qui reste à prouver
Pour la vitesse des attaques, les sources convergent. Pour le nombre de failles, c'est moins net : aucun chiffre ne prouve que l'IA explique la hausse de 2025, et Patchstack note même qu'une partie vient de signalements bâclés, générés par IA, qui ne sont pas de vraies failles.
Un dernier chiffre, moins confortable : 46 % des vulnérabilités de 2025 n'avaient pas de correctif au moment où elles ont été rendues publiques (Patchstack). Mettre à jour vite ne suffit pas toujours, parce qu'il n'y a parfois rien à installer.
Au vu de ce qui se passe sur Firefox et de ce que décrit Anthropic, je m'attends à ce que le rythme d'août et septembre devienne la norme plutôt que l'exception.
Ce que ça change pour votre site
Si les attaques arrivent en quelques heures, la question n'est plus de savoir si votre site sera testé, mais s'il sera à jour ce jour-là. J'ai listé les gestes concrets à la fin de l'enquête sur ma préprod : savoir qui applique les mises à jour, protéger les préprods, déplacer la page de connexion, ajouter un pare-feu, choisir un hébergeur qui surveille.
Il y a un geste que je mets aujourd'hui au-dessus des autres : une sauvegarde hors-site. Plus les attaques sont rapides et nombreuses, plus il devient probable qu'une d'elles passe un jour entre les mailles, par exemple par une faille qui n'a pas encore de correctif. Ce jour-là, une sauvegarde stockée sur le même serveur que le site ne sert à rien : l'attaquant qui a pris la main sur le site peut l'effacer ou la corrompre avec le reste. Seule une copie conservée ailleurs, chez un autre prestataire, garantit de repartir d'un état sain. J'ai détaillé la règle du « 3-2-1 » dans ce qui casse sur un WordPress sans maintenance.
Si vous préférez ne pas y penser, c'est le travail de ma maintenance WordPress : je suis les failles publiées, j'applique les mises à jour et je vérifie les sauvegardes hors-site.