Core Security Initiative : WordPress fait scanner son cœur par une IA avant les pirates

Pendant vingt ans, la sécurité de WordPress a fonctionné dans un seul sens : un chercheur trouve une faille, la signale, l’équipe corrige, une version sort. Efficace, mais entièrement dépendante du fait que quelqu’un d’extérieur regarde le code avant les pirates. Et sur un logiciel qui fait tourner une part énorme du web, c’est une position d’attente inconfortable.

Le 28 août 2026, Rudy Faile a publié sur le blog sécurité de WordPress un billet intitulé The Core Security Initiative, qui annonce un changement de posture en trois chantiers. Le plus intéressant pour nous : WordPress veut faire scanner son propre code par des outils assistés par IA pour trouver les failles avant qu’un rapport n’arrive. Je vous explique ce que contient réellement l’initiative, ce qu’elle ne dit pas (et il y a beaucoup à dire là-dessus), comment elle s’articule avec le resserrement du programme de divulgation annoncé quatre jours plus tard, ce qu’en dit le premier bilan publié le 29 octobre, et ce que ça change concrètement pour votre site. Petit conseil pour la fin : rien, ou presque, et je vous dirai pourquoi c’est plutôt une bonne nouvelle.

Les trois piliers de l’initiative

Le billet structure l’effort autour de trois axes, présentés sous forme d’abécédaire A, B, C.

A comme « A better release process ». Il s’agit de rendre le processus de publication des correctifs de sécurité plus resserré et plus automatisé, avec des tests renforcés pour garantir la fiabilité des correctifs livrés. Traduction pour vous : moins de délai entre le correctif et sa mise à disposition, et moins de risques qu’une version de sécurité casse quelque chose au passage. Quiconque a déjà vu une mise à jour mineure planter un site en production comprend l’intérêt de la seconde moitié de la phrase.

B comme « Breaking the backlog ». L’équipe sécurité s’élargit pour traiter la file d’attente des rapports en souffrance, avec un objectif affiché de ramener les problèmes connus à zéro. C’est le pilier le moins spectaculaire et probablement le plus utile. Une faille signalée qui dort six mois dans une file d’attente est une faille connue de son découvreur, et potentiellement d’autres.

C comme « Crush vulnerabilities with AI ». Le troisième pilier prévoit d’appliquer des outils de balayage assistés par IA pour détecter les failles avant leur exploitation, en complément des signalements par divulgation responsable. C’est le renversement de logique : au lieu d’attendre qu’on lui signale un problème, le projet part le chercher lui-même dans son propre code.

Le scan IA : ce qui est annoncé, et tout ce qui ne l’est pas

Voilà pour l’annonce. En pratique, le billet reste extrêmement vague, et il faut le dire clairement plutôt que de commenter du vent.

Le billet du 28 août ne nomme aucun outil. On ne sait pas s’il s’agit d’un service commercial d’analyse de code, d’un modèle utilisé en interne, ou d’un assemblage maison. Il ne précise pas non plus le périmètre : le cœur seulement, Gutenberg, les thèmes par défaut, les plugins de l’équipe ? Il ne dit pas si le dispositif tourne déjà ou s’il est au stade de l’intention. Et il n’annonce ni objectif chiffré, ni calendrier.

Je ne le dis pas pour taper sur l’annonce. Un billet d’intention n’a pas vocation à livrer une architecture technique, et il vaut mieux annoncer une direction qu’un plan détaillé qu’on ne tiendra pas. Mais ça voulait dire que, début septembre, la seule chose vérifiable était l’intention elle-même. Lire à ce moment-là que « WordPress scanne désormais son code avec une IA », au présent, relevait de l’extrapolation. Le bilan publié fin octobre a changé la donne, je le détaille plus bas.

Ce qu’il faut aussi garder en tête sur le fond : l’analyse statique assistée par IA est très bonne pour repérer les motifs connus, une entrée non échappée, une capacité mal vérifiée, une requête concaténée. Elle est nettement moins bonne sur les failles de logique métier, celles qui naissent de l’enchaînement de deux comportements corrects pris séparément. C’est précisément ce type de faille que les bons chercheurs trouvent. Le scan automatisé viendra en complément des humains, pas à leur place, et le billet ne prétend d’ailleurs pas le contraire.

Le second étage : le tri des signalements a changé le 1er septembre

Quatre jours après l’initiative, le 1er septembre 2026, Ehtisham Siddiqui a publié une mise à jour du programme de divulgation des vulnérabilités, explicitement rattachée à la Core Security Initiative. Elle resserre ce qui est recevable.

Les chercheurs sont invités à se concentrer sur les failles à impact clair, en particulier celles exploitables sans authentification ou par un utilisateur à faibles privilèges comme un Abonné. À l’inverse, pour les actifs qui ne relèvent ni du cœur ni de Gutenberg, les vulnérabilités nécessitant un rôle qu’un administrateur est le seul à pouvoir attribuer ne seront généralement plus éligibles, sauf à démontrer une escalade de privilèges de haute sévérité. Même chose pour les cas où un rôle authentifié peut effectuer une action normalement réservée à un autre rôle authentifié, sans impact sévère derrière.

Cette logique se défend. Une faille qui exige qu’un administrateur ait d’abord nommé quelqu’un Éditeur suppose un attaquant déjà à moitié dans la place. Ce n’est pas le même risque qu’une faille exploitable par n’importe quel visiteur ayant créé un compte sur votre site. Trier, c’est reconnaître qu’on n’a pas des ressources infinies, et l’annoncer publiquement vaut mieux que de laisser mourir les rapports dans une file.

Reste un effet de bord à surveiller : ce qui n’est plus « éligible » au programme ne devient pas inoffensif pour autant. Si vous faites tourner un site avec des comptes Contributeur ou Auteur ouverts à des rédacteurs externes, les failles inter-rôles vous concernent directement, même quand elles sortent du périmètre du programme. Elles seront simplement moins vite documentées. Le cœur et Gutenberg restent, pour l’instant, sous les anciennes règles d’éligibilité : huit des corrections listées dans WordPress 7.1.4 concernent d’ailleurs des failles exploitables avec un simple rôle Contributeur.

Mise à jour : ce que le bilan du 29 octobre a confirmé

Deux mois après l’annonce, Rudy Faile a publié le 29 octobre 2026 un premier bilan chiffré de l’initiative. Il répond à plusieurs questions que le billet de départ laissait ouvertes.

Le contexte d’abord. Pendant une dizaine d’années, le programme de signalement de WordPress sur HackerOne recevait 20 à 30 rapports par mois. Il en a reçu 450 en juillet 2026 et 773 en août. Plus de 3 000 rapports sont arrivés depuis le début de l’année, davantage que sur les douze années précédentes réunies. Le billet du 28 août attribuait déjà une bonne part de cette hausse aux progrès des modèles d’IA, qui rendent l’analyse de code à la recherche de failles beaucoup plus simple.

Pour le pilier A, quatre versions de sécurité sont sorties en 41 jours : 7.1.1 le 17 septembre, 7.1.2 le 22 septembre, 7.1.3 le 6 octobre et 7.1.4 le 28 octobre. Chaque correctif a été reporté sur toutes les branches encore maintenues, jusqu’à WordPress 4.7. Sur les 109 étapes d’une version de sécurité, 73 % sont désormais automatisées.

Pour le pilier B, l’équipe a mis en place un tri assisté par IA : le système lit chaque rapport, tente de le reproduire dans un environnement isolé et propose un avis sur sa validité et sa gravité. La décision finale revient toujours à un membre de l’équipe sécurité. Près de 3 000 rapports ont été clôturés depuis janvier, et la file des rapports non triés est passée de 359 à quelques dizaines.

Pour le pilier C, le même outillage sert maintenant à chercher des failles dans le cœur avant tout signalement, avec des modèles à poids ouverts (open-weight) et des outils développés sur mesure. Aucun modèle n’est nommé. WordPress a aussi été inscrit à l’OSS Scanner d’Anthropic, un programme d’analyses gratuites pour les projets open source, et l’équipe a commencé à corriger les premiers résultats. Anthropic figure parmi les rapporteurs crédités dans les notes de 7.1.1, 7.1.3 et 7.1.4, et Trail of Bits, associé à OpenAI, dans celles de 7.1.3.

Le scan par IA n’est donc plus une simple intention. Il ne remplace pas les chercheurs pour autant : sur les 17 corrections listées dans les notes de la version 7.1.4, deux sont créditées à Anthropic, les autres à des chercheurs et à des membres de l’équipe sécurité.

Ce que ça change pour votre site : rien à régler, des correctifs plus fréquents

Aucun réglage à modifier, aucune extension à installer. Ces trois chantiers se déroulent en amont, dans la fabrique du logiciel. Leur effet visible de votre côté, c’est le rythme : quatre versions de sécurité entre le 17 septembre et le 28 octobre 2026. Vérifiez simplement que vos sites ont bien reçu la dernière (7.1.4 au moment où j’écris ces lignes), ce que les mises à jour automatiques de sécurité font normalement sans vous.

Ce qui compte, c’est ce que ça produira en aval, et là il faut être lucide : la meilleure détection du monde ne protège que les sites qui appliquent les correctifs. Les compromissions que je vois passer ne viennent presque jamais d’une faille inconnue du cœur. Elles viennent d’une extension pas mise à jour depuis huit mois, d’un thème abandonné par son auteur, ou d’un compte administrateur avec un mot de passe recyclé. Le cœur de WordPress est déjà l’une des parties les mieux surveillées de votre installation, comme l’ont montré l’épisode wp2shell et la faille RCE de WordPress 7.0.4, tous deux corrigés vite.

Autrement dit, cette initiative renforce l’étage qui vous protégeait déjà le mieux. Le vôtre, celui de la mise à jour de vos extensions, reste exactement là où il était. Si vous gérez plusieurs sites, c’est le moment de vérifier que vous avez un tableau de bord centralisé plutôt qu’une bonne mémoire, et MainWP fait très bien le travail gratuitement.

Les signaux que je surveille dans les prochains mois

Une annonce se juge à ce qu’elle produit. Voici les trois choses concrètes que je vais regarder, et que vous pouvez regarder aussi. Le bilan du 29 octobre apporte déjà un premier élément de réponse à chacune.

• Le délai entre correctif et publication. Si le pilier A tient ses promesses, les versions de sécurité doivent sortir plus vite et sans régression. Une version de sécurité qui casse un site et qu’il faut corriger dans la foulée serait le premier signal négatif. Fin octobre : quatre versions en 41 jours, publiées en deux vagues en commençant par les versions de WordPress les plus utilisées.
• L’origine des failles corrigées. Le jour où un billet de sécurité mentionnera une faille trouvée en interne par balayage automatisé, et pas par un chercheur externe, le pilier C sera devenu réel. Tant que toutes les entrées créditent un chercheur, c’est que l’outillage n’a rien produit de publiable. Fin octobre, le signal est en partie là : les notes de la version 7.1.4 créditent deux failles à Anthropic, dont WordPress utilise l’OSS Scanner. Les scans menés en interne par l’équipe ne sont pas encore identifiés comme tels dans les crédits.
• La file d’attente des rapports. L’objectif « zéro problème connu » est ambitieux au point d’être invérifiable de l’extérieur. Un point d’étape chiffré publié par l’équipe serait le meilleur indicateur de sérieux. Le premier est arrivé le 29 octobre : la file des rapports non triés est passée de 359 à quelques dizaines. Reste à voir si elle s’y maintient.

Mon avis

C’est une bonne direction, prise avec un vocabulaire un peu trop marketing pour un billet technique. Le pilier B, celui dont personne ne parlera, est de loin le plus utile à court terme. Le pilier C fera les titres pendant six mois et ne se jugera qu’à ses résultats publiés. Les premiers sont déjà visibles dans les notes de version, avec des failles signalées par Anthropic corrigées dès WordPress 7.1.1.

Deux choses à faire en refermant cet article, et aucune ne concerne l’IA. Vérifiez que les mises à jour automatiques de sécurité sont bien actives sur vos sites, elles le sont par défaut mais un plugin de maintenance les désactive parfois sans le dire. Et passez en revue vos extensions inactives : celles que vous n’utilisez plus restent du code exécutable sur votre serveur, et aucun scan côté WordPress.org ne viendra les surveiller pour vous. Le reste des fondamentaux tient dans un article, et il n’a pas changé depuis l’annonce du 28 août.