La société de sécurité Wiz a publié le 17 août une recherche décrivant comment son agent offensif autonome a découvert et exploité une vulnérabilité d’injection de script dans un workflow GitHub Actions appartenant au dépôt public snowflakedb/snowflake-connector-net, et s’en est servi pour exfiltrer un jeton donnant accès en lecture au Jira interne de Snowflake.

Le calendrier est inhabituellement serré

La vulnérabilité est apparue lorsque la PR #1218 a été fusionnée le 18 juin 2026. Wiz l’a identifiée, exploitée et signalée via HackerOne le 23 juin ; Snowflake a corrigé le problème le jour même dans le commit 1dc7766, puis a fait tourner le jeton Jira le 24 juin. La fenêtre d’exposition a duré cinq jours. Le jeton authentifiait l’identité qa@snowflake.net auprès du tenant Atlassian de Snowflake, offrant un accès en lecture aux projets de génie logiciel, de conformité sécurité et de suivi des bugs bounty.

Ce que le cadrage dominant présente mal

L’affaire circule sous la forme : « une IA a écrit le bug et une autre IA l’a exploité ». Cette symétrie est précisément la partie que personne ne peut revendiquer. La position de GitHub, communiquée aux journalistes, est que les contributions ayant conduit à la vulnérabilité ont été rédigées par un humain et n’ont été ni relues ni contribuéées par Copilot. Le billet de Wiz ajoute lui-même une mise à jour admettant qu’il n’est pas clair si la modification du code a été assistée par l’IA, et précise que la contribution documentée de Copilot Autofix dans cette pull request était une correction distincte apportée à un autre fichier. L’attribution de la paternité est donc contestée par l’éditeur et nuancée par la chercheuse — mais c’est pourtant cette version qui domine la couverture.

Le constat incontesté est le plus grave

Ce que personne ne conteste : un agent autonome a assemblé seul toute la chaîne d’attaque — reconnaissance, découverte d’un workflow injectable, exploitation, exfiltration d’identifiants et mouvement latéral vers un système SaaS distinct — contre un grand fournisseur de plateforme de données. Et quoi qu’il en soit de l’auteur de la faille, les propres outils de détection de GitHub ne l’ont pas signalée avant la fusion. C’est un constat sur la couverture défensive, et il ne dépend en rien du débat sur la paternité.

Ce qui a été atteint — et ce qui ne l’a pas été

Une troisième distorsion mérite d’être nommée. Il s’agissait du workflow CI d’un dépôt public de connecteur, et l’accès obtenu portait sur des projets Jira en lecture seule. Il ne s’agissait pas de la plateforme de données Snowflake, ni de données clients. Snowflake indique que son enquête n’a révélé aucune preuve d’accès non autorisé au-delà des chercheurs, et que les journaux d’audit montraient que Wiz était le seul tiers présent sur l’endpoint. « Snowflake piratée » et « lecture de Jira via un runner Actions » ne sont pas la même phrase.