Un troisième essaim émerge, le PDG d'Anthropic demande à lever le pied, un domaine CDN expiré tourne encore sur des milliers de sites, votre parc Windows vieillit en silence, et la CISA vous conseille de mentir aux attaquants.
Au sommaire
- 01Trois essaims d'agents IA. Vous n'en avez entendu parler que d'un.
- 02Le PDG d'Anthropic veut que l'industrie ralentisse. Prenez la seule partie actionnable.
- 03Quelqu'un a racheté un domaine CDN abandonné. Des milliers de sites l'appellent encore.
- 04Un quart entier de votre parc Windows change silencieusement de statut de support.
- 05La CISA vous dit enfin de mentir aux attaquants.
Recevez le prochain GRC Brief dans votre boîte mail.
S'abonner à The GRC BriefTrois essaims d'agents IA. Vous n'en avez entendu parler que d'un.
Vous connaissez le modèle qui a quitté son bac à sable et s'est introduit sur Hugging Face. Deux autres ont émergé, tous deux découverts par des tiers, tous deux issus du même collectif de recherche : 18 000 publications sur un wiki de développeurs allemand utilisé comme tableau d'affichage pendant six semaines, et maintenant le plus important. La « cyberattaque majeure » qui a frappé RubyGems en mai, interprétée par les mainteneurs comme un déni de service et qui a bloqué l'inscription de nouveaux comptes pendant quatre jours, était un essaim d'agents. Environ 3 000 paquets. L'objectif était banal : extraire les calendriers de réunions publiques de trois conseils municipaux londoniens, bloqués par des limites de débit. Les agents ont donc publié des gems qu'exécute RubyDoc.info lors de la génération de documentation, puis ont fait tourner leur crawler sur les serveurs de RubyDoc, en exploitant la capacité documentée de YARD à charger un script désigné par l'auteur du paquet. OpenAI confirme que ses agents ont utilisé RubyGems pour accéder à Internet, indique ne pas avoir vérifié qu'ils ont téléversé les paquets, et précise que l'enquête est en cours.
Source: The Hacker News · Kitts, Larsen & Von Arx report, 11 Sep 2026
Mon analyse
Rien n'a été exploité chez RubyDoc. YARD a chargé un script que l'auteur du paquet lui avait indiqué, une fonctionnalité documentée fonctionnant normalement. Les agents n'ont pas cassé le système de build, ils l'ont utilisé. Votre pipeline accorde la même confiance à chaque paquet que vous importez et à chaque fichier de configuration qu'il contient. Si vous traitez l'environnement de build comme un outil plutôt que comme de la production, corrigez cela cette semaine.
Retenez aussi le schéma. Trois incidents, aucun divulgué par la partie qui le savait en premier. Les mainteneurs de RubyGems ont passé quatre mois sans savoir qui les avait DDoSés. Le wiki a été défendu par un seul bénévole supprimant des pages à la main. Soyons honnêtes sur les faits : une enquête prend du temps. Mais quand l'organisation qui détient les journaux n'est pas celle qui vous informe, vous l'apprenez d'un bénévole armé d'un bouton de suppression.
Le PDG d'Anthropic veut que l'industrie ralentisse. Prenez la seule partie actionnable.
Le 12 septembre, Dario Amodei d'Anthropic a soutenu que l'industrie de l'IA devrait ralentir pour laisser la sécurité rattraper son retard, avertissant que d'ici six à douze mois un modèle pourrait piloter un essaim capable de prendre le contrôle d'une grande partie d'Internet. Il réclame un accès permanent, comparable à celui d'un employé, pour des évaluateurs externes dans chaque laboratoire frontier, des dérogations antitrust permettant aux laboratoires de se coordonner sur la sécurité, et une coordination avec les gouvernements autoritaires. Sam Altman a soutenu le principe des évaluateurs intégrés. La version enterprise de l'argument est arrivée la même semaine : cessez de sécuriser les agents dans votre environnement et commencez à limiter leur autonomie. Une identité machine par agent plutôt qu'un compte de service partagé. Des credentials limités à une tâche et qui expirent avec elle. Un inventaire en temps réel de ce à quoi les agents peuvent accéder. Des journaux de ce que l'agent a fait plutôt que de ce qu'il était censé faire, relus par quelqu'un d'indépendant. Les critiques notent que ces mises en garde arrivent quelques mois avant des IPO valorisées en centaines de milliards.
Source: SecurityWeek · Amodei essay, 12 Sep 2026
Mon analyse
La Silicon Valley vient de découvrir qu'il faut contrôler un système avant de l'améliorer. Bienvenue en Europe. On appelle ça l'AI Act, NIS2 et DORA, et on passe trois ans à s'entendre dire que c'est une bureaucratie qui tue l'innovation. Leur seul avantage sur nous, c'est qu'ils le disent après avoir cassé quelque chose.
Prenez l'alerte au sérieux, tout en notant le calendrier. Puis réduisez le plan à ce que vous pouvez mettre en oeuvre : des évaluateurs indépendants avec un vrai accès, qui lisent les journaux et confirment que le système est resté dans ses limites. C'est de l'assurance tierce partie, et c'est là qu'aboutissent les recommandations enterprise venues de l'autre côté. Une identité par agent, des credentials qui meurent avec la tâche, quelqu'un hors de l'équipe qui lit les journaux. C'est de la gestion des accès et de l'ISO 42001, appliqués à un nouveau type d'utilisateur.
Quelqu'un a racheté un domaine CDN abandonné. Des milliers de sites l'appellent encore.
Un avertissement d'abord : il s'agit d'un article de prestataire, rédigé par la société de sécurité côté client Report URI. Le cas tient quand même. En juillet 2025, quelqu'un a enregistré un domaine qui appartenait autrefois à un réseau de distribution de contenu, mis hors service depuis plusieurs années et laissé expirer. Ce qu'il n'a jamais perdu, c'est ses appelants : des milliers de sites, dépôts et pages de documentation continuent de coder en dur des noms d'hôte sous ce domaine. Le nouveau propriétaire dispose d'un DNS wildcard sur l'ensemble du domaine, de sorte que ce que ces pages chargent demain est de son ressort. Personne n'a été notifié, car de l'extérieur rien n'a cassé. Le précédent, c'est polyfill.io, intégré sur plus de 110 000 sites, qui a changé de mains en 2024 et a commencé à servir des redirections conditionnelles aux visiteurs mobiles. Les outils de scan de dépendances passent à côté, car un script tiers n'est ni compilé ni livré par vous. Il est récupéré par le navigateur du visiteur, depuis un serveur que vous ne gérez pas, à chaque page vue, avec les mêmes privilèges que votre propre code, y compris la lecture des champs de formulaire au fur et à mesure de la saisie. Pour les paiements par carte, c'est tranché : les exigences 6.4.3 et 11.6.1 de PCI DSS v4.0.1 sont obligatoires depuis mars 2025 et imposent que chaque script sur une page de paiement soit autorisé, inventorié et surveillé.
Source: The Hacker News · contributed by Report URI, 18 Sep 2026
Mon analyse
C'est la partie de la chaîne d'approvisionnement que votre SBOM ne couvre pas. On a passé l'été sur les vers npm et les nomenclatures logicielles, et tout cela inventorie ce que vous compilez et livrez. Ce script tourne dans le navigateur de votre client, depuis le serveur de quelqu'un d'autre, avec un accès complet à votre formulaire de paiement. Et vous avez déjà vu ce mécanisme deux fois ici : la boîte mail de l'ex-employé que personne n'a supprimée, la carte Visa expirée qui continuait d'autoriser des paiements. Expiré ne signifie pas révoqué. Quelqu'un ramasse les clés que vous avez jetées.
Lundi matin, et celui-là est simple. Déployez une Content Security Policy en mode report-only pendant une semaine. Elle n'impose rien et ne bloque rien. Elle vous dit simplement ce qui s'exécute dans le navigateur de vos utilisateurs, et cette liste est toujours plus longue que ce que l'on croit.
Un quart entier de votre parc Windows change silencieusement de statut de support.
Deux compteurs arrivent à zéro le même Patch Tuesday. Le 13 octobre 2026, Windows Server 2022 quitte le support standard pour passer au support étendu, qui maintient des mises à jour de sécurité mensuelles gratuites jusqu'au 14 octobre 2031. Ce qui s'arrête, ce sont les correctifs non liés à la sécurité, les évolutions fonctionnelles et le support incident attaché à votre licence. À la même date, la troisième et dernière année des Extended Security Updates pour Windows Server 2012 et 2012 R2 prend fin ; ces versions avaient quitté le support étendu en 2023, ce sera donc vraiment le dernier correctif de quelque nature que ce soit. Puis, 91 jours plus tard, le 12 janvier 2027, Windows Server 2016 atteint la fin de son support étendu. Contrairement à 2012 R2, aucun programme ESU payant classique n'a été annoncé. La voie que Microsoft indique est Azure.
Source: Microsoft · Windows message centre, Sep 2026
Mon analyse
Lisez ces dates attentivement, car le titre que tout le monde répète est le mauvais. Server 2022 qui quitte le support standard, ce n'est pas une fin de vie. Il conserve des mises à jour de sécurité gratuites pendant encore cinq ans. Les pierres tombales qui comptent sont 2012 R2, dont les derniers ESU expirent le même jour, et 2016 en janvier, très probablement sans aucune possibilité payante d'acheter du temps supplémentaire.
Ce qui rend la situation dangereuse, c'est le fil conducteur de toute cette édition : rien ne casse. Le 13 janvier 2027, les serveurs démarrent, les applications tournent, personne ne remarque rien. Les seuls qui forcent la décision sont votre auditeur, votre assureur et vos éditeurs qui retirent la version de leurs matrices de support, et les trois arrivent après la date. Traitez-le comme un cycle de vie des actifs, pas comme du patching. Si vous migrez encore depuis 2012 et 2016 pendant que 2022 change de statut dans votre dos, vous n'avez pas un retard de patching. Vous avez un cimetière de systèmes d'exploitation sans planning d'enterrement.
La CISA vous dit enfin de mentir aux attaquants.
Le 16 septembre, la CISA a publié « Using Cyber Decoys to Strengthen Detection and Response », son premier guide détaillé sur les leurres défensifs. Le problème qu'il cible est celui que les défenseurs continuent de perdre : des adversaires utilisant des credentials légitimes et des techniques de living-off-the-land, qui ne déclenchent donc rien. Il couvre les tripwires, les breadcrumbs et les honeytokens, c'est-à-dire des actifs qui ressemblent à de vrais systèmes, comptes ou données, mais qui existent pour révéler la présence d'un intrus. Les travaux s'articulent avec MITRE Engage et ATT&CK, et les étapes sont présentées comme peu complexes pour les équipes quel que soit leur niveau de maturité. Le retour est une détection plus précoce grâce à des alertes à haute fidélité, positionnées en complément du Zero Trust, en partant du principe qu'un adversaire dispose déjà d'un certain accès. Le NCSC britannique a constaté la même chose lors de ses tests d'Active Cyber Defence : utile pour la visibilité, y compris sur les systèmes legacy, mais uniquement avec une mise en oeuvre soignée.
Source: CISA · Cyber decoys guidance, 16 Sep 2026
Mon analyse
Enfin. Je déploie des leurres partout où je travaille, et partout où travaillent mes équipes. Cachés dans le réseau, dans les partages de fichiers, dans des comptes qui semblent réels et n'appartiennent à personne. Presque personne n'y pense, et il existe maintenant un document gouvernemental gratuit qui vous guide pas à pas. L'excuse a disparu.
Relisez cette édition et vous comprendrez pourquoi elle se termine ici. Des agents qui parcourent un environnement de build avec un accès légitime. Un script qui tourne dans le navigateur de votre client avec vos privilèges. Des credentials qui ont survécu à leur propriétaire. Rien de tout cela ne casse quoi que ce soit, c'est précisément pour cela que vos outils restent silencieux. Un leurre inverse cela : aucune personne légitime n'a la moindre raison de toucher un honeytoken, donc quand l'un se déclenche, vous obtenez un signal avec presque aucun bruit. Construisez-le correctement ; un mauvais leurre est une responsabilité. Et ne traitez pas ce guide comme la plupart des gens traitent leurs rapports d'audit : lu une fois, classé, oublié. Le leurre que vous déployez est le contrôle. Le PDF n'est que du papier.