Sécurité à l'ère de l'IA : la veille n'est plus une option

Cet article a un compagnon : stackalarm. Un outil open source, une skill pour agent de code et une CLI, qui lit environ 90 sources de sécurité (éditeurs, CERT, bases de CVE, exploits publics) et les confronte au projet ouvert : il suffit de taper /stackalarm pour savoir ce qui, dans l’actualité de la semaine, touche ce dépôt et quoi corriger en premier. C’est une première piste, volontairement minimaliste, présentée plus bas.

Mardi soir, 21h32

Le mardi 20 octobre, à 21h32 heure de Paris, l’équipe sécurité de PHP publie un message de quelques lignes. Une version de sécurité sortira le lendemain, mercredi, à 14h00 UTC. Elle corrigera deux vulnérabilités critiques, notées 9,2 sur 10. Les utilisateurs sont invités à se préparer, et la publication pourra être avancée si les détails fuitent ou si une exploitation est observée.

Je l’ai vu passer le soir même, sur les réseaux sociaux. Pas dans un outil, pas dans un tableau de bord : dans mon fil, entre deux autres publications. En quelques minutes, les messages se multipliaient, des chercheurs en sécurité commentaient, des identifiants de CVE circulaient déjà. Tout indiquait que l’affaire allait prendre de l’ampleur. J’ai écrit à mes collègues sur notre messagerie d’équipe : je pense que demain, ceci va nous occuper. J’ai aussi prévenu quelques personnes de mon entourage dont je sais qu’elles font tourner du PHP.

Le lendemain, la faille avait un nom, PHP2Shell, et le ministère de l’Intérieur mettait hors ligne les sites des préfectures, à titre préventif et à la demande de l’ANSSI. Aux Pays-Bas et en Finlande, des services publics avaient été débranchés avant même la sortie du correctif.

Cette nuit-là, j’étais prévenu. Mais je l’étais par chance : parce que le bon message était passé dans mon fil au bon moment, et parce que je suis le genre de personne qui lit ces messages-là. C’est de cette chance que parle ce billet.

Une semaine, trois alertes

Prises isolément, ces alertes auraient chacune mérité attention. Ensemble, elles dessinent un changement de rythme.

PHP2Shell

Deux failles dans le cœur de PHP (CVE-2026-109618 et CVE-2026-109619) permettent d’exécuter du code à distance sans authentification, sur toutes les façons de servir PHP sur le web : PHP-FPM, mod_php, FrankenPHP, LiteSpeed. Selon l’une des équipes à l’origine de la découverte, le code en cause remonte à PHP 5.4, sorti en 2012. Les correctifs sont sortis le mercredi 21 octobre, et les branches 7.4 à 8.1, en fin de vie, n’ont reçu que des correctifs sous forme de code source.

Le piège : mettre à jour son framework ou son CMS ne protégeait de rien, puisque la faille est dans le runtime. Et une image Docker construite sur un tag flottant comme php:8.3-fpm restait vulnérable tant qu’elle n’était pas reconstruite.

Node.js et le décodeur Brotli

Le même mercredi, Node.js corrigeait dix failles, dont une écriture hors limites dans son décodeur Brotli (CVE-2026-111497), avec un risque d’exécution de code à distance. Le piège : selon plusieurs analyses, le fetch() natif de Node décompresse lui-même les réponses Brotli. Une application qui va chercher une URL fournie par un utilisateur expose donc le décodeur vulnérable à n’importe quel serveur malveillant. Node 20, qui n’est plus maintenu, ne reçoit pas de correctif.

GitLab, deux fois

Le 12 octobre, GitLab corrigeait une exécution de code sans authentification notée 10 sur 10, via une expression régulière piégée dans une configuration de CI. Le 21, une seconde faille notée 10, dans la même zone de code et trouvée par le même chercheur, touchait toutes les versions depuis la 7.0. Le piège : une instance mise à jour consciencieusement le 12 était de nouveau vulnérable le 21.

Ce qui a changé

Des failles critiques, il y en a toujours eu. Ce qui m’a frappé cette semaine, ce sont deux choses : la vitesse, avec le rôle qu’y joue l’IA, et le chaos de la divulgation.

L’IA trouve, l’IA exploite

PHP2Shell a été découverte en août par un chercheur de la société Calif, dans le cadre du programme Patch the Planet d’OpenAI, avec l’aide d’un modèle GPT. Les équipes de Wiz l’ont trouvée de leur côté, et les deux entreprises disent avoir utilisé des modèles d’IA. Le détail le plus parlant : les premiers signes du problème avaient été repérés dès 2024, lors d’un audit externe du code de PHP. Faute de vecteur d’exploitation concret, d’autres corrections avaient été jugées prioritaires, et le bug était resté en l’état. Avec l’IA, la preuve qu’il était exploitable a été apportée en deux semaines.

La faille Brotli de Node.js, elle, est créditée à Codex Security, l’outil d’analyse de sécurité d’OpenAI.

Côté attaque, la logique est la même. En juin, une étude de l’équipe Frontier Red Team d’Anthropic a mesuré ce que les modèles récents savent faire à partir d’un correctif publié : comparer le code avant et après, en déduire la vulnérabilité, écrire l’exploit. Sur des correctifs de Firefox, le premier exploit complet arrivait en moins d’une heure. Sur des correctifs du noyau Windows, des chaînes complètes d’élévation de privilèges coûtaient environ 2 000 dollars de crédits d’API chacune. Les auteurs concluent que parler de « N-day » (une faille connue et corrigée, mais pas encore partout) devient trompeur : « N-hour is closer to the reality », autrement dit, c’est désormais en heures qu’il faut compter.

PHP2Shell l’a illustré en direct. Amazon a observé une première tentative d’exploitation dans ses pots de miel le 17 octobre, quatre jours avant la divulgation. Le lendemain de la sortie des correctifs, un exploit était publié sur Exploit-DB, dont l’en-tête précise qu’il a été adapté avec l’aide de l’IA. Cloudflare, watchTowr et Amazon signalaient déjà des tentatives d’attaque.

En face, nos organisations ne vont pas plus vite. Selon le rapport Verizon 2026 sur les fuites de données, cité par The Hacker News, le délai médian pour corriger une vulnérabilité critique est passé de 32 à 43 jours. L’écart ne se réduit pas : il se creuse.

Le chaos de la divulgation

La divulgation coordonnée repose sur un équilibre fragile : les mainteneurs préparent les correctifs en silence, puis publient tout en même temps, pour que les défenseurs aient une longueur d’avance. Cette semaine, l’équilibre a cédé de partout.

La divulgation coordonnée visait au départ le jeudi. Mais dès le mardi après-midi, des identifiants de CVE et de faux scores de gravité fuitaient sur les réseaux sociaux : c’est ce qui a poussé l’équipe PHP à annoncer, le soir même, une sortie dès le mercredi. Une vidéo de démonstration était publiée par erreur par l’une des équipes à l’origine de la découverte. Le mercredi matin, un éditeur publiait ses propres images corrigées avant la sortie officielle, offrant aux attaquants la possibilité de comparer le code. Les avis de sécurité sont finalement sortis 26 minutes avant l’heure annoncée.

Ce n’est la faute de personne en particulier. C’est le signe qu’un processus pensé pour un monde où exploiter une faille demandait des semaines ne tient plus quand quelques heures suffisent. La PHP Foundation a d’ailleurs reconnu que le retard pris sur ce bug était un « échec structurel », et annoncé que son équipe sécurité pourrait désormais trancher à la majorité.

Pourquoi les outils habituels arrivent trop tard

Dans l’équipe, comme dans beaucoup d’autres, la mise à jour des dépendances est automatisée avec Renovate, et les audits de dépendances (composer audit, npm audit) tournent régulièrement. Ces outils sont précieux, mais face à cette semaine, ils avaient deux limites.

La première, c’est leur périmètre. Les audits lisent les lockfiles : ils comparent les bibliothèques déclarées dans composer.lock ou package-lock.json aux bases d’avis de sécurité, et ne voient ni le langage lui-même, ni l’image Docker de base. Les outils de mise à jour vont plus loin, puisqu’ils savent aussi faire monter une image ou une version de runtime déclarée dans le dépôt. Mais une instance GitLab auto-hébergée, elle, ne figure dans aucun fichier du projet.

La seconde, c’est leur rythme. Un outil de mise à jour tourne selon son propre calendrier, souvent la nuit ou une fois par semaine, puis la mise à jour doit être relue et déployée. Quand un exploit circule quelques heures après le correctif, cette fenêtre laisse la production exposée bien trop longtemps. Et une annonce préalable, par définition, ne correspond encore à aucune version à installer.

Le mardi soir, ma veille reposait donc sur trois piliers : les flux d’alerte des CERT, Renovate, et les réseaux sociaux. L’alerte du CERT-FR est arrivée le mercredi, avec les correctifs. Renovate n’aurait proposé la mise à jour qu’à son prochain passage. Ce sont les réseaux sociaux, la source la moins fiable des trois, qui ont fait la différence.

Qui fait la veille ?

Une fois l’urgence passée, j’en ai parlé avec mon CEO, ancien DSI pendant plus de vingt ans. La question qui nous a occupés était simple, et inconfortable : que se serait-il passé si je n’avais pas donné l’alerte ce mardi soir ?

Nous avons d’abord constaté que, lui comme moi, nous faisons de la veille sans vraiment nous en rendre compte. Nous suivons des comptes spécialisés en cybersécurité, le sujet nous intéresse, et nous lisons ces messages-là quand ils passent. Lui a passé des années à gérer ces questions. Moi, j’ai toujours eu cette sensibilité, encore plus ces derniers mois, et mon périmètre, ce sont justement les applications exposées sur Internet. Pour moi, la veille fait partie intégrante de mon travail.

Mais une veille qui repose sur deux personnes sensibilisées, qui lisent leur fil au bon moment, c’est une veille fragile. Il suffit d’un congé, d’une soirée sans écran, d’un algorithme de recommandation qui décide de mettre autre chose en avant.

Alors, qui doit faire la veille ? Le tech lead ? Chaque développeur ? Nous sommes tombés d’accord sur le principe : idéalement, ce devrait être une partie du travail de chacun. Et sur la difficulté : c’est très compliqué à organiser. Demander à toute une équipe de suivre les bons comptes sur les réseaux sociaux n’est pas une méthode. Distribuer la lecture de dizaines de flux non plus.

Nous en avons conclu qu’il fallait chercher à automatiser cette veille, ou au moins à la simplifier assez pour qu’elle ne dépende plus de la chance.

Une méthode pour suivre sa propre stack

Suivre « l’actualité cyber » en général noie sous le bruit. La question utile est plus étroite : est-ce que ce qui vient de sortir touche ce que je fais tourner ? Voici la méthode que j’en ai tirée.

Connaître ce qu’on fait tourner

On ne peut pas surveiller ce qu’on ne connaît pas. Trois couches méritent d’être recensées pour chaque projet :

• Les runtimes : la version de PHP, de Node.js, de Python, l’image Docker de base et la distribution qui est dessous.
• Les dépendances : celles des lockfiles, que les audits savent déjà traiter.
• Les outils auto-hébergés : la forge, la CI, les bases de données, le serveur web.

Pour chacun, la version exacte compte. Un "php": ">=8.2" dans un composer.json ou un tag php:8.3-fpm dans un Dockerfile ne disent pas ce qui tourne réellement en production. Et il faut connaître les dates de fin de support : un site comme endoflife.date les rassemble. PHP2Shell l’a rappelé, une version en fin de vie ne reçoit pas toujours de correctif utilisable.

S’abonner aux sources qui parlent en premier

Pour chaque brique, les éditeurs publient leurs propres annonces, souvent avant tout le monde :

• PHP : le flux des releases et les actualités de php.net, et la catégorie internals du Discourse de la PHP Foundation, où l’annonce du mardi est apparue.
• Node.js : la page des rapports de vulnérabilité de nodejs.org. L’équipe annonce généralement ses versions de sécurité quelques jours à l’avance (six jours en juillet 2026), ce qui laisse le temps de réserver un créneau de déploiement.
• GitLab : le flux des patch releases, publiées à un rythme régulier, avec des versions critiques hors calendrier.
• Frameworks et bibliothèques : les avis de sécurité GitHub des projets (php-src, Symfony, Laravel, Rails…) et la GitHub Advisory Database par écosystème.
• Distributions : les avis de sécurité de Debian, d’Ubuntu ou d’Alpine, pour les images de base.

À cela s’ajoutent les sources générales :

• Les CERT : le CERT-FR sépare ses alertes, rares et critiques, de ses avis, nombreux. Suivre les alertes suffit pour ne rien rater de majeur. Le CERT-EU, la CISA américaine ou le NCSC britannique jouent le même rôle.
• Les bases de vulnérabilités : la NVD américaine et l’EUVD européenne, tenue par l’ENISA, recensent les CVE. Elles sont exhaustives, donc bruyantes : elles servent à vérifier, pas à être lues en entier.
• Les listes de diffusion comme oss-security, où les annonces préalables circulent souvent tôt.

Distinguer l’urgent du reste

Le score CVSS donne une gravité théorique, pas un risque réel. Deux signaux gratuits aident à trier :

• Le catalogue KEV de la CISA liste les vulnérabilités effectivement exploitées. Une faille qui y figure se corrige sans attendre.
• Le score EPSS estime la probabilité qu’une faille soit exploitée dans les trente jours.

J’y ajoute un troisième : la publication d’un exploit public, sur Exploit-DB par exemple. Depuis que l’IA raccourcit le délai entre un correctif et son exploitation, ce signal arrive vite.

La règle que je retiens est simple : un composant exposé sur Internet, une exécution de code sans authentification, et un exploit public ou une exploitation signalée, c’est une correction le jour même. Le reste suit le rythme normal des mises à jour.

Préparer le réflexe

Une veille sans réaction préparée ne sert pas à grand-chose. Le jour où l’alerte tombe, il faut savoir qui corrige quoi, comment reconstruire et redéployer une image, comment isoler ou couper un service si le correctif tarde. Les éditeurs publient parfois des mesures d’atténuation temporaires : pour PHP2Shell, désactiver session.upload_progress.enabled réduisait l’exposition sans la supprimer. Et ces mesures ne sont pas forcément temporaires : deux jours après les correctifs, un nouvel avis de php.net recommandait de garder ce réglage désactivé jusqu’à la prochaine version, à cause d’une variante encore non corrigée (CVE-2026-115560). Une veille ne s’arrête pas le jour du correctif.

Un dernier point, souvent oublié : la recherche de traces d’intrusion doit commencer à la date de la première exploitation connue, pas à celle de la divulgation. Pour PHP2Shell, cela voulait dire remonter au 17 octobre.

Une piste : stackalarm

Cette méthode a un défaut évident : elle demande du temps et de la régularité, exactement ce qui manque quand la veille repose sur la bonne volonté de quelques personnes. Pour explorer la piste de l’automatisation, j’ai commencé à construire un outil : stackalarm.

Open source, sous licence MIT. Le code de la CLI, la skill et la liste des sources sont publics sur GitHub. Le projet est ouvert aux contributions, qui passent par les issues : la plus utile est une nouvelle source à surveiller, avec un formulaire dédié qui demande juste l’adresse du flux, les technologies concernées et ce qu’il annonce. Les retours d’usage et les idées pour la skill sont tout aussi bienvenus.

L’idée part d’un constat : lire des dizaines de flux et les confronter à un projet, c’est précisément le genre de travail pour lequel un agent d’IA est doué, à condition qu’il sache où regarder. stackalarm est donc fait de deux parties, qui ne servent à rien l’une sans l’autre.

Une CLI lit environ 90 sources directement : annonces et releases des projets, avis des éditeurs, GitHub Advisory Database, NVD et EUVD, CERT américains, européens, canadiens et japonais, catalogue KEV, Exploit-DB, et une partie de la presse spécialisée. Elle ne fait aucune analyse : elle rassemble, date et classe les informations selon leur étape, de l’annonce préalable jusqu’à l’exploitation signalée.

Une skill pour agent de code (Claude Code, Codex, Cursor et d’autres) fait le travail d’analyse. Elle lit le projet ouvert (manifestes, lockfiles, Dockerfiles, configuration de CI, dépôt distant) pour identifier les technologies et leurs versions. Elle interroge la CLI, complète par une recherche web et par les audits de dépendances de l’écosystème, puis décide de ce qui s’applique vraiment. Elle dit à quel point elle est sûre d’elle, pose la question qui changerait son verdict (souvent : quelle version tourne en production ?), et propose de corriger ce qui se trouve dans le dépôt, une modification à la fois, après accord. Elle ne pousse rien, ne déploie rien et ne touche à aucun serveur.

L’installation tient en deux commandes :

brew install yoanbernabeu/tap/stackalarm
npx skills add yoanbernabeu/stackalarm

Ensuite, dans un projet, il suffit d’appeler la skill explicitement :

/stackalarm
/stackalarm avant la mise en production de vendredi

Sur un projet Symfony avec une instance GitLab auto-hébergée, au lendemain de cette semaine, la réponse ressemblait à ceci :

Verdict : oui, il faut agir aujourd'hui sur deux points critiques.

🔴 À faire maintenant
- PHP2Shell (CVE-2026-109618 et CVE-2026-109619) : le Dockerfile utilise
  php:8.3-fpm, un tag flottant. La production est possiblement affectée,
  selon la date de construction de l'image. Un exploit est public.
  Reconstruire avec --pull, redéployer, vérifier que php -v affiche 8.3.36.
- GitLab CVE-2026-110264 (CVSS 10) : le dépôt distant pointe vers une
  instance auto-hébergée. Versions corrigées : 19.5.1, 19.4.3, 19.3.6…
  Quelle version tourne sur l'instance ?

🟠 À préparer
- Symfony 7.3 ne reçoit plus de correctifs de sécurité : une faille de
  HttpFoundation publiée le 15 octobre n'est corrigée qu'en 7.4.

Vérifié : sources PHP, Symfony, Composer, GitLab, CERT, NVD, EUVD,
recherche web, composer audit.
Non vérifié : la version de PHP réellement en production.

C’est d’ailleurs stackalarm qui m’a signalé, le 23 octobre au matin, l’avis complémentaire de php.net sur session.upload_progress, avant que je le voie passer ailleurs.

Je l’ai aussi lancé sur ce blog. Verdict : à préparer, rien d’urgent. Node.js était bien concerné par la faille Brotli, mais le site est statique : Node ne tourne qu’au moment de construire les pages et dans une tâche planifiée qui n’interroge que des API de confiance. Le point le plus utile était ailleurs. L’hébergeur et la CI étaient configurés avec une simple branche de Node (« 24 » pour l’un, « 22 » pour l’autre), qui peut très bien rester sur une version déjà en cache, donc non corrigée. J’ai fixé les versions exactes. C’est typiquement le genre de détail qu’aucun audit de dépendances ne voit.

La CLI s’utilise aussi seule, pour lire l’actualité brute d’une technologie :

stackalarm news --tag php --tag gitlab --since 7d

Pour être clair sur ce que c’est : un embryon. stackalarm est volontairement minimaliste. Il s’utilise en local, à la demande, dans un projet ouvert. On pourrait aller beaucoup plus loin : le brancher dans une CI, le lancer chaque matin, ouvrir automatiquement des tickets, prévenir l’équipe sur la messagerie. J’ai préféré commencer par la version la plus simple qui réponde à la question de départ, et voir à l’usage ce qui manque vraiment.

Il a aussi ses limites. La qualité de l’analyse dépend du modèle utilisé. Une recherche web ne vaut jamais une source officielle, et la skill est conçue pour privilégier ces dernières. La version qui tourne en production reste souvent inconnue depuis le dépôt, d’où la question systématique. Enfin, il ne remplace ni Renovate ni les audits de dépendances : il les complète, sur ce qu’ils ne couvrent pas et sur ce qu’ils voient trop tard.

Plusieurs mois de chaos

Il n’y a pas de paradoxe à répondre à une IA qui attaque par une IA qui défend. Les défenseurs l’utiliseront, les attaquants aussi : c’est la même course, et elle a commencé.

Je pense que nous devons nous attendre à plusieurs mois de chaos. Les outils d’analyse assistés par l’IA vont déterrer des failles anciennes, comme ce bug de PHP présent depuis 2012, à un rythme que les mainteneurs n’ont jamais connu. Il faudra les corriger, souvent dans l’urgence, avec des équipes open source qui n’ont pas été dimensionnées pour ça. J’espère que la situation se stabilisera, que les processus de divulgation et les outils s’adapteront. Mais pendant un bon moment, ce sera très agité.

Dans ce contexte, la veille n’est plus une affaire de curiosité personnelle ou de passionnés qui suivent les bons comptes. C’est une partie du travail de quiconque fait tourner quelque chose sur Internet. Rester alerte n’est pas de la paranoïa : c’est de l’hygiène. Et ce mardi soir, la différence entre une équipe prévenue la veille et une équipe qui découvre la faille dans ses journaux tenait à un message lu au bon moment. Il est temps de ne plus compter sur la chance.