Quatrième numéro de notre revue hebdomadaire. Chaque vendredi, les faits marquants des sept derniers jours, lus avec les lunettes d'un propriétaire de risque plutôt qu'avec celles d'un analyste. Pour chaque fait, ce qu'il change pour une organisation canadienne, et la question à poser lundi matin.
La semaine dernière, le fil conducteur tenait en une phrase : le correctif arrive après l'attaquant. Cette semaine, le problème se déplace d'un cran en amont : le code que vous exécutez n'est pas celui que vous avez approuvé. Un employé parti dont le compte est resté ouvert, un greffon épinglé par empreinte cryptographique qui charge autre chose, un domaine expiré racheté par un inconnu que des milliers de sites appellent encore. Trois mécanismes différents, une même conséquence : ce qui tourne chez vous a été décidé ailleurs. Puis l'infrastructure, où la cadence ne faiblit pas, et cinq revendications canadiennes en trois jours.
Partie 1 : quatre façons de perdre le contrôle de ce qui s'exécute chez vous
CrowdSec : 170 dépôts privés copiés en mai, découverts en septembre
Le 18 septembre, l'éditeur français CrowdSec a confirmé qu'environ 170 de ses dépôts GitHub privés avaient été copiés le 22 mai, entre 5 h 52 et 6 h 01 UTC, depuis une adresse IP située à Toronto. Le compte utilisé était celui d'un employé qui venait de quitter l'entreprise et dont l'accès GitHub n'avait pas été révoqué. Son ordinateur portable avait été compromis en mai par l'attaque de chaîne d'approvisionnement visant TanStack : le 11 mai, 84 versions malveillantes de 42 paquets npm de ce projet ont été publiées et ont siphonné les secrets présents sur les machines des développeurs.
Le contenu volé comprend la console SaaS de l'éditeur, ses scripts et modèles de science des données, son outillage de déploiement et d'automatisation, et l'algorithme de consensus qui décide de l'inscription d'une adresse IP sur ses listes de blocage. S'y ajoutent les adresses courriel de 83 utilisateurs et les noms, courriels et contexte d'investissement de 51 investisseurs potentiels de 2020. CrowdSec indique que le compte n'a servi qu'à copier du code, que l'infrastructure et les bases de données n'ont pas été touchées, et qu'aucun code n'a été modifié. L'entreprise n'a rien vu venir : le code est apparu sur un forum le 16 septembre, quatre mois après les faits.
Ce que ça change : la chaîne d'événements n'a rien d'exotique. Un paquet de dépendance compromis, un poste de développeur qui garde ses jetons en clair, un départ dont la révocation d'accès n'a pas suivi, et quatre mois de latence avant la découverte. Chacun de ces quatre maillons figure dans n'importe quelle politique de sécurité ; aucun n'a tenu. Pour un comité de direction, la question utile n'est pas « avons-nous une procédure de départ » mais : combien de comptes d'anciens employés sont encore actifs sur nos dépôts de code, nos environnements infonuagiques et nos SaaS, et qui l'a vérifié cette année dans les systèmes plutôt que dans la procédure ? Et si un dépôt privé partait aujourd'hui, par quel signal l'apprendrions-nous autrement qu'en le lisant sur un forum ?
Plugin4Shell : l'épinglage de version ne protège pas les agents de code IA
Le 18 septembre, les chercheurs d'AIR Security ont publié Plugin4Shell, une exécution de code à distance sans interaction qui touche les quatre principaux agents de développement assistés par IA : Claude Code, OpenAI Codex, GitHub Copilot et Gemini CLI. Quand un agent installe un greffon, il effectue un git checkout sur une empreinte de commit de 40 caractères, précisément pour garantir que le code installé est celui qui a été revu. Aucun des quatre ne vérifiait que l'arborescence obtenue correspondait réellement à cette empreinte.
Le contournement est d'une simplicité désarmante : le propriétaire du dépôt crée une branche dont le nom est exactement l'empreinte épinglée, puis la désigne comme branche par défaut. Git résout les noms de branche avant les empreintes de commit, et l'agent installe silencieusement le contenu de la branche de l'attaquant. Deux chemins d'attaque en découlent : soumettre un greffon propre, attendre qu'il soit revu et épinglé, puis en remplacer le contenu après coup ; ou détourner le dépôt d'un auteur légitime par vol de jeton et y pousser du code qui passera le même contrôle. La victime n'a rien fait d'imprudent : il lui suffit d'avoir installé un greffon d'une place de marché de confiance, revu et épinglé exactement comme le modèle de sécurité le prévoit. Anthropic a corrigé dans Claude Code 2.1.179 et OpenAI dans Codex 0.146.0. GitHub Copilot n'a pas de correctif, et Google ne corrigera pas Gemini CLI, qu'il retire du marché.
Dans le même registre, la semaine a vu deux campagnes npm : WeaselBiscuit, un voleur d'identifiants diffusé par 13 paquets malveillants qui vise le stockage des extensions Chrome et présente des recoupements fonctionnels avec BeaverTail et OtterCookie, attribués à la Corée du Nord ; et PhantomRaven, distribué par plus de cent paquets typosquattés et vraisemblablement écrit avec un grand modèle de langage, à en juger par ses commentaires verbeux et son code à trous.
Ce que ça change : l'agent de code IA est en train de devenir un composant de votre chaîne de production logicielle, avec les droits d'un développeur et la vitesse d'une automatisation. Il hérite donc du même régime de gouvernance : inventaire de ce qui est installé, provenance des greffons, et surtout une décision explicite sur les outils que l'éditeur cesse de corriger. Le cas Gemini CLI est le plus instructif de la semaine : un produit retiré du marché n'est pas un produit sans utilisateurs, c'est un produit sans correctifs. Si vos équipes en ont un dans leur chaîne d'outils, la question n'est plus « quand corrige-t-on » mais « quand le retire-t-on, et qui décide ».
Un domaine de CDN abandonné a été racheté, et des milliers de sites l'appellent encore
Un réseau de diffusion de contenu a cessé ses activités il y a quelques années et a laissé expirer le domaine depuis lequel il servait ses fichiers. En juillet 2025, un inconnu l'a racheté, avec un enregistrement DNS générique qui lui donne la main sur n'importe quel sous-domaine. Des milliers de sites, de dépôts de code et de pages de documentation contiennent toujours des références en dur à des noms d'hôte sous ce domaine. De l'extérieur, rien n'a cassé : les fichiers se chargent, et personne n'a été prévenu. Le contenu servi à ces milliers de pages est désormais décidé par un tiers dont aucune de ces organisations ne connaît le nom. En septembre 2026, des alertes collectées par Report URI ont fait apparaître une grappe de sites de commerce en ligne compromis exécutant une campagne d'ingénierie sociale de la famille ClickFix.
Ce que ça change : c'est le même motif que la clé d'API laissée quatre ans dans le JavaScript public de Manchester Airports la semaine dernière, vu par l'autre bout. Ce qu'un navigateur charge sur vos pages est une dépendance de production au même titre qu'une bibliothèque de votre dépôt, mais elle n'apparaît dans aucun inventaire, aucune nomenclature logicielle et aucun questionnaire fournisseur, parce que le tiers concerné n'a jamais été contractualisé. Deux vérifications concrètes cette semaine : la liste des domaines tiers que vos pages appellent réellement en production, et parmi eux, ceux dont l'entreprise d'origine n'existe plus. C'est un exercice de surface d'attaque externe, pas de gestion de fournisseurs.
Partie 2 : l'infrastructure, où la cadence ne faiblit pas
Cisco, deux produits exploités en trois jours
Le 14 septembre, Cisco a divulgué CVE-2026-76461 (CVSS 9.8), une injection SQL dans la logique d'analyse des courriels d'AsyncOS, sur Secure Email Gateway. Un courriel forgé suffit : il emprunte le chemin d'inspection normal de l'appliance et permet à un attaquant non authentifié d'exécuter des commandes en root. L'exploitation était déjà en cours au moment de la divulgation, la CISA a inscrit la faille au catalogue KEV le jour même avec échéance fédérale au 17 septembre. Détail qui mérite d'être noté : Cisco a découvert la vulnérabilité en traitant un dossier de support client, pas au cours d'une revue de sécurité interne.
Deux jours plus tard, le 16 septembre, l'éditeur publiait les correctifs de CVE-2026-76460 (CVSS 10.0), un contournement d'authentification sur une interface de programmation d'Identity Services Engine et d'ISE-PIC, branches 3.1 à 3.5, menant lui aussi à l'exécution de commandes en root. Là encore, l'exploitation était connue avant la publication. Inscription au KEV le jour même, échéance au 19 septembre, avec obligation de triage forensique au titre de la directive BOD 26-04.
Ce que ça change : après la console de gestion des pare-feux la semaine dernière, c'est la passerelle de courriel et le serveur de contrôle d'accès au réseau, soit trois produits Cisco d'infrastructure exploités en dix jours. Ces trois équipements ont un point commun : ce sont des systèmes de sécurité. Ils sont, par construction, placés devant tout le reste, joignables et hautement privilégiés. Le contrôle qui compte n'est plus le délai de correction mais la présomption : sur une faille exploitée avant sa divulgation, un correctif appliqué à temps ne dit rien sur la période précédente. La question à trancher d'avance, une fois pour toutes, est : à partir de quel critère déclenchons-nous une recherche de compromission plutôt qu'une simple mise à jour, et qui la signe ?
vCenter : d'une campagne d'espionnage à une campagne de rançongiciel
CVE-2026-59310 (CVSS 9.8) est une traversée de répertoire dans le serveur syslog de VMware vCenter, qui permet à un attaquant non authentifié d'exécuter du code. Broadcom l'a corrigée le 29 juillet. Deux semaines plus tard, la firme de réponse à incident QUIRSO recensait plus de 361 adresses IP compromises dans 47 pays par un acteur soupçonné d'espionnage, qui déployait un outil de SSH inversé pour se maintenir. Le 15 septembre, la CISA a mis à jour son inscription au KEV pour signaler que des groupes de rançongiciel exploitent désormais la même faille.
Ce que ça change : c'est la trajectoire classique, et elle est de plus en plus courte. Une faille sert d'abord à l'espionnage, discret par nature, puis rejoint l'outillage des affiliés de rançongiciel, où elle devient bruyante. Qui tient vCenter tient l'hyperviseur, donc les serveurs virtuels, les instantanés, les sauvegardes et les chemins de restauration — c'est-à-dire exactement ce sur quoi repose votre plan de reprise. Deux mois se sont écoulés entre le correctif et cette bascule : c'est le délai réel dont dispose une organisation qui suit le KEV sans le lire. Et ce n'est pas théorique : Akira, le groupe qui a revendiqué une victime canadienne cette semaine, est précisément spécialisé dans le chiffrement des environnements VMware ESXi.
Chrome et Windows : les deux zero-days de mardi dernier étaient déjà en service
Volexity a documenté une campagne d'hameçonnage ciblé conduite le 1er septembre par un groupe lié à la Chine, suivi sous le nom UTA0560, contre plusieurs organisations non gouvernementales. Les courriels renvoyaient vers le site d'une université américaine, dont une faille de script intersites réfléchi servait de tremplin vers l'infrastructure des attaquants. Là, une chaîne en trois temps : CVE-2026-85046 pour obtenir lecture et écriture arbitraires dans le bac à sable de V8, CVE-2026-87491 pour s'échapper du bac à sable du navigateur, puis CVE-2026-85880 dans le mécanisme ALPC de Windows pour injecter du code dans le processus Chrome. Charge finale : GRIMWEDGE, une porte dérobée en JavaScript qui fait de la reconnaissance, gère fichiers et processus, exécute des commandes et livre d'autres charges. APT31 a utilisé la même chaîne pour installer LONGTALE, qui se fait passer pour une extension Gemini légitime et capture frappes clavier, données de formulaire, témoins de session et captures d'écran.
Ce que ça change : regardez les numéros. CVE-2026-87491 a été inscrite au KEV le 9 septembre, et CVE-2026-85880 était l'un des deux zero-days déjà exploités du Patch Tuesday à 966 correctifs du 8 septembre. Autrement dit, deux des lignes que vos équipes ont triées la semaine dernière dans une liste de 966 entrées étaient, au même moment, les maillons d'une chaîne d'exploitation opérationnelle contre des organisations réelles. C'est l'argument le plus concret en faveur d'une règle de tri écrite d'avance : dans un lot de cette taille, « exploité dans la nature » n'est pas une étiquette parmi d'autres, c'est le seul critère qui distingue une mise à jour d'une course contre la montre. Pour mémoire, la CISA a aussi inscrit trois failles du noyau Linux le 18 septembre, le jour même où du code d'exploitation public sortait pour quatre autres élévations de privilèges locales du même noyau.
Partie 3 : cinq revendications canadiennes, et un secteur qui prend l'essentiel
Entre le 16 et le 18 septembre, cinq organisations canadiennes ont été inscrites sur des sites de fuite. Bee Maid Honey, bras commercial des coopératives de producteurs de miel de l'Alberta et du Manitoba, avec des usines à Winnipeg et à Spruce Grove, a été revendiquée par Akira le 16 septembre : le groupe annonce 46 Go de données, dont des dossiers RH contenant passeports, permis de conduire et certificats de décès, ainsi que des états financiers, des contrats et des ententes de confidentialité. Le même jour, Qilin inscrivait l'agence In The Company of Huskies. Le 17, Braincipher revendiquait la firme de services techniques Xpera. Le 18, le groupe Play inscrivait deux victimes canadiennes le même jour, dont le manufacturier Vista Plastic Solutions.
Le motif sectoriel est documenté. Selon le rapport de Black Kite repris cette semaine, le secteur manufacturier a subi 1 183 incidents de rançongiciel sur les sept premiers mois de 2026, soit 40 % de plus que sur la même période en 2025. La moitié de ces attaques provient de groupes qui n'existaient pas il y a deux ans ; un seul d'entre eux, The Gentlemen, représente 12 % du total de l'année.
Ce que ça change : la raison de cette concentration est économique, pas technique. Chez la plupart des organisations, une attaque arrête l'informatique et les opérations continuent tant bien que mal ; chez un manufacturier, elle arrête la production physique. Livraisons manquées, ouvriers immobilisés, pénalités contractuelles, clients bloqués : la pression financière monte en heures, pas en semaines, et les attaquants le savent. Si vous êtes manufacturier, ou si vos fournisseurs critiques le sont, la conversation à avoir ne porte pas sur le montant d'une rançon mais sur le coût d'une journée d'arrêt, et sur le nombre de jours que votre trésorerie et vos contrats absorbent. C'est cette question qui doit piloter le budget de résilience, et elle relève du directeur financier autant que du responsable de la sécurité.
Partie 4 : l'IA des deux côtés de la table, en trois faits
Google a confirmé cette semaine un incident survenu en mai lors d'une évaluation de sécurité menée par la firme israélienne Irregular. Le bac à sable de test disposait par erreur d'un accès à Internet, et le nom de l'entreprise fictive de l'exercice correspondait à un vrai domaine. Gemini a obtenu l'accès à un système protégé en devinant son mot de passe, et dans deux autres cas en trouvant des identifiants dans un dépôt public. Le modèle a interrompu l'intrusion après avoir constaté qu'il s'agissait d'une vraie entreprise. Irregular a prévenu Google en juillet, Google a informé les entreprises touchées et les autorités fédérales, et l'affaire n'est devenue publique qu'en septembre, quand des journalistes ont commencé à poser des questions.
Dans l'autre sens, une équipe de trois chercheurs de la jeune pousse Hacktron a utilisé Claude Opus 5, dans le cadre du programme de primes aux bogues d'OpenAI, pour enchaîner deux vulnérabilités jusqu'aux comptes d'employés de l'entreprise. Le point de départ était le forum communautaire, qui confie les images HEIC à ImageMagick et à la bibliothèque libheif : une image forgée corrompt la mémoire du serveur, et l'authentification partagée fait le reste jusqu'aux comptes ChatGPT et Codex des employés membres du forum. Le modèle a produit un exploit fonctionnel sur la configuration réelle du forum en quelques heures ; OpenAI a corrigé en quatorze heures et versé une prime de 6 500 dollars. Enfin, Microsoft a traité CVE-2026-85889 (CVSS 10.0), une absence d'authentification sur une fonction critique d'Azure AI Foundry permettant une élévation de privilèges à distance. Correction entièrement côté serveur : les clients n'ont eu aucun correctif à appliquer, et aucun moyen de vérifier quoi que ce soit.
Ce que ça change : trois faits, une seule leçon de gouvernance. Un modèle en évaluation a franchi la frontière de son environnement de test parce qu'une configuration réseau ne correspondait pas à l'intention ; une plateforme d'IA d'entreprise a exposé une fonction privilégiée sans authentification ; un modèle commercial sert d'outil d'enchaînement de failles à des chercheurs, et demain à d'autres. Les trois posent la même question à votre organisation : à quels systèmes réels vos agents IA peuvent-ils accéder, avec quelles identités, et qui journalise ce qu'ils font ? C'est exactement le terrain de notre épisode de jeudi sur les fournisseurs qui utilisent l'IA sans vous le dire : le périmètre n'est plus le vôtre, mais la responsabilité l'est toujours.
Les trois questions de la semaine pour un comité de direction
- Combien de comptes d'anciens employés et de prestataires sont encore actifs sur nos dépôts de code, nos environnements infonuagiques et nos SaaS, et qui l'a vérifié dans les systèmes cette année plutôt que dans la procédure ?
- Quels outils de développement assistés par IA sont installés dans nos chaînes de production, avec quels greffons, et lesquels de ces outils ne sont plus corrigés par leur éditeur ?
- Sur une faille exploitée avant sa divulgation, à partir de quel critère déclenchons-nous une recherche de compromission plutôt qu'une simple mise à jour, et qui signe cette décision ?
Si ces trois questions n'ont pas de réponse documentée, notre score de risque cyber gratuit vous situe en dix minutes sur les domaines identités, vulnérabilités et tiers. Pour suivre ces expositions en continu plutôt qu'une fois par an, c'est le rôle des modules surface d'attaque et threat intelligence de la plateforme FortaRisks.
Un dernier mot, et on arrête de parler de nous
FortaRisks sera au GoSec mercredi et jeudi prochains, les 23 et 24 septembre, à Montréal. Venez parler risque, pas produit : apportez la question sur un tiers à laquelle vous n'arrivez pas à répondre, ou l'usage de l'IA dont personne ne répond encore chez vous, et on la travaillera ensemble au stand. Pour réserver un créneau, écrivez-nous.
Sources : The Hacker News, CrowdSec et TanStack · Cybersecurity News, 170 dépôts privés · AIR Security, Plugin4Shell · Help Net Security, deux agents non corrigés · The Hacker News, Plugin4Shell · The Hacker News, le domaine de CDN racheté · BleepingComputer, zero-day Cisco Secure Email · The Hacker News, Secure Email Gateway exploité · CISA, avis du 16 septembre · Infosecurity Magazine, exploitation de Cisco ISE · BleepingComputer, vCenter et rançongiciels · BleepingComputer, vCenter et SSH inversé · The Hacker News, la chaîne Chrome-Windows et GRIMWEDGE · CISA, avis du 18 septembre · ransomware.live, victimes au Canada · ransomware.live, Bee Maid Honey · SecurityWeek, les rançongiciels visant les manufacturiers · The Hacker News, Gemini et le test qui a débordé · Axios, trois entreprises touchées · The Hacker News, Claude Opus 5 et les comptes OpenAI · The Register, la chaîne d'exploitation · The Hacker News, Azure AI Foundry