Le jeton Jira de Snowflake : une faille que Copilot a cosignée, et un humain que GitHub désigne comme l'auteur

Le 23 juin 2026, Red Agent, un agent de sécurité autonome développé par Wiz, a ouvert un ticket sur un dépôt GitHub public appartenant à Snowflake et en est revenu avec un identifiant d'authentification. Le dépôt était snowflakedb/snowflake-connector-net, et le workflow en cause, .github/workflows/jira_issue.yml, sert à créer un ticket Jira chaque fois que quelqu'un ouvre un ticket — il intégrait le titre du ticket dans une commande shell au lieu de le transmettre via une variable d'environnement, si bien qu'un titre habilement conçu s'exécutait comme du code sur le runner GitHub Actions. Le jeton récupéré par Red Agent s'authentifiait en tant que qa@snowflake.net auprès de snowflakecomputing.atlassian.net et donnait un accès en lecture aux projets Jira engineering, security-compliance et bug-bounty de Snowflake. La faille était active depuis cinq jours. Wiz a publié son analyse complète le 17 août 2026. Cet incident est répertorié sous la référence 2026-08-17-snowflake-jira-zhao-dao-can dans l'Orca AI Incident Archive, qui contient l'ensemble des enregistrements avec leurs niveaux de confiance et leurs sources citées.

L’interpolation, et la garde qui ne s’est jamais exécutée

Le workflow a été déclenché par l'événement GitHub « issues: opened ». Toute personne disposant d'un compte GitHub pouvait le déclencher en ouvrant une issue sur un dépôt public — sans invitation, sans rôle de mainteneur, sans fork. L'étape vulnérable lisait le titre de l'issue dans une variable shell : TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), avec deux filtres censés échapper les guillemets doubles et les guillemets simples avant l'assemblage de la chaîne.

Le problème réside dans l’ordre des opérations, et non dans l’échappement. GitHub substitue le contenu de l’expression dans le texte du script avant même que bash ne l’analyse, de sorte qu’une apostrophe dans le titre du ticket ferme la chaîne entre guillemets que echo garde ouverte. Les deux filtres sed s’exécutent dans ce même script, après la substitution, et ne peuvent pas corriger un échappement qui a déjà modifié la façon dont la ligne est analysée. Le compte rendu de Wiz indique explicitement que l’échappement intervient trop tard pour empêcher l’évasion, et qu’un titre conçu avec un guillemet fermant et un point-virgule ajoute des commandes choisies par l’attaquant à l’étape d’exécution.

Un second contrôle était censé restreindre le public et ne l’a pas fait. Le job comportait une condition if comparant github.event.pull_request.user.login au login du bot whitesource-for-github-com, manifestement pour empêcher les pull requests automatisées de dépendances de créer des tickets. Lors d’un événement issues, il n’y a aucun objet pull request, la comparaison porte donc sur une propriété nulle. La documentation de GitHub, citée par The Hacker News, indique que le déréférencement d’une propriété inexistante s’évalue à une chaîne vide ; l’analyse de Wiz aboutit au même résultat via la valeur null. Dans les deux cas, la condition s’évaluait à true pour chaque utilisateur, et l’exception prévue pour le bot s’est transformée en laissez-passer pour tout Internet.

Ce qui faisait de l’injection un cas à signaler plutôt qu’une routine, c’est l’environnement dans lequel elle s’inscrivait. La même étape contenait JIRA_BASE_URL, JIRA_USER_EMAIL et JIRA_API_TOKEN comme variables d’environnement, de sorte qu’une exécution arbitraire de commandes sur le runner avait un identifiant à portée de main plutôt qu’un substrat vierge. Aucune version publiée de Snowflake Connector for .NET n’a été identifiée comme affectée : la faiblesse résidait dans l’automatisation CI/CD du dépôt, et non dans le code du connecteur livré.

Ce que Red Agent a pris, et ce qu’il dit avoir jeté

Le récit de Wiz sur l’exploitation est ce qui distingue ceci d’une découverte de scanner. La première charge utile utilisait un caractère dièse, qui commentait la parenthèse fermante de l’affectation TITLE=$(...) et produisait une erreur de syntaxe bash au lieu d’un callback. L’agent a lu l’erreur et a réécrit la charge utile pour fermer le bloc shell avec un point-virgule et un nouveau guillemet pour echo, puis a reçu un appel hors bande. La charge utile utilisait curl pour atteindre un sous-domaine de oast.me avec les valeurs encodées en base64 des trois variables d’identifiants, et le callback est arrivé depuis l’IP Azure 20.106.182.197, une adresse que Wiz attribue à un runner GitHub Actions.

Le jeton qu’il a renvoyé était un jeton d’API Jira pour qa@snowflake.net, et Wiz décrit sa portée comme un accès en lecture couvrant les projets d’ingénierie, de conformité en matière de sécurité et de suivi des primes aux bogues sur l’instance cloud Atlassian de Snowflake. C’est là le préjudice que consigne l’archive : non pas une exécution de code sur une machine de build pendant cinq jours, mais un identifiant qui pouvait lire les files de tickets où sont déclarés les bogues d’ingénierie et de sécurité non corrigés — y compris, selon la description de Wiz, le suivi des primes aux bogues.

Wiz affirme avoir supprimé de manière sécurisée tout ce à quoi il a eu accès pendant la preuve de concept. Snowflake, dans une déclaration à CSO Online, a indiqué que le rapport « a été immédiatement examiné et corrigé » et que « notre enquête n'a trouvé aucune preuve d'accès non autorisé » ; le blog de Wiz ajoute que Snowflake a examiné les journaux d'audit sur la période de cinq jours et n'a trouvé aucune utilisation par un tiers en dehors des propres adresses de test de Wiz. Snowflake n'a pas publié ces journaux, de sorte que la conclusion selon laquelle aucun autre acteur n'est intervenu repose sur sa version des faits et sur le résumé qu'en fait Wiz, plutôt que sur des documents que toute personne extérieure aux deux organisations peut lire.

Qui a écrit la ligne vulnérable ?

Cette question a donné lieu à la seconde histoire, plus importante. La PR #1218, intitulée « SNOW-2069227: Update jira workflows », a été fusionnée par squash le 18 juin 2026 en tant que commit 4a1b8ce, et le commit de squash liste Copilot Autofix powered by AI parmi ses coauteurs. Le titre initial de Wiz reposait exactement là-dessus, décrivant la faille comme présente dans une pull request assistée par GitHub Copilot, et les premiers articles de la presse spécialisée ont suivi la même ligne — le titre de SC Media était « Wiz agent finds Snowflake repo flaw in code co-authored by GitHub Copilot Autofix ».

La position de GitHub, rapportée par The Next Web et résumée dans une note de recherche de la Cloud Security Alliance, est que son examen interne a conclu qu'« un humain a écrit les contributions qui ont mené à la vulnérabilité » et que Copilot Autofix « ne les a ni examinées ni contribué à celles-ci ». Le fondement technique de cette réfutation se trouve dans l'historique git. Le squash-merge réduit une pull request à un seul commit et reporte chaque trailer de co-auteur, quelles que soient les lignes touchées par cet auteur ; une ligne de co-auteur enregistre donc une participation à la pull request, et non la paternité d'un hunk particulier. Le commit co-signé par Copilot dans cette même pull request, 6d0e2fa, modifiait jira_close.yml — un workflow différent du jira_issue.yml vulnérable. L'interpolation non sécurisée est attribuée au commit 094038e, daté du 25 août 2025 et attribué par GitHub à un ingénieur Snowflake, sfc-gh-hpathak ; la PR #1218 a introduit ce schéma sur la branche par défaut en juin 2026.

Wiz n'a pas retiré son constat, et a modifié la présentation le jour de la publication. Son blog contient une mise à jour publiée à 19:57 UTC le 17 août, décrivant Copilot comme « un co-auteur qui a vérifié la PR fusionnée et la modification du code », qui « a conclu que tout était en ordre » sans remarquer les vulnérabilités, et en admettant que « il n'est pas clair que la modification du code ait été assistée par l'IA ». Dans cette version, la défaillance de l'IA relève de la revue, et non de la paternité du code : la pull request fusionnée portait une co-signature de Copilot et l'injection y a survécu. CSO Online cite Ami Luttwak, CTO de Wiz, qui déclare que l'attribution claire entre les humains et l'IA « devient un peu plus difficile à établir », et que « regarder uniquement les co-auteurs de la PR ne suffit pas ».

Ce que les deux versions ont en commun mérite d’être distingué de ce qu’elles contestent. Les deux s’accordent sur le fait que le commit squash porte le trailer de co-auteur de Copilot Autofix et que le workflow était exploitable. Aucune ne conteste que GitHub Advanced Security ait analysé la révision finale de la pull request, extrait jira_issue.yml et n’ait pas signalé l’injection — Wiz le qualifie d’omission, et la réfutation de GitHub porte sur la paternité plutôt que sur l’analyse. Ce qui reste non résolu, c’est de savoir si Copilot a examiné les lignes vulnérables, même un tant soit peu : Wiz affirme qu’une revue a été exécutée et les a validées, GitHub affirme que l’outil n’a joué aucun rôle à leur sujet, et les journaux qui permettraient de trancher sont entre les mains de l’une des deux entreprises. Le dossier consigne les deux versions plutôt que de trancher.

Cinq jours, et ce qui a changé ensuite

La réparation a été rapide une fois le rapport arrivé. Wiz a déposé le rapport n° 3819931 via le programme HackerOne de Snowflake le 23 juin et a informé l’équipe de sécurité de Snowflake par Slack le jour même ; Snowflake a fusionné la PR n° 1402, commit 1dc7766, qui remplaçait l’expansion directe d’expression par des variables d’environnement transmises à jq en tant qu’arguments. La chronologie de Wiz situe la rotation du jeton Jira au 24 juin, et The Hacker News rapporte la même répartition. L’introduction de Wiz elle-même, en revanche, indique que Snowflake a corrigé la vulnérabilité et effectué la rotation de l’identifiant « le jour même » — une divergence au sein de la source primaire que le compte rendu ne devrait pas masquer. La correction a été déployée le 23 juin ; la rotation est datée du 24 juin dans le tableau de Wiz.

La divulgation a suivi le calendrier de Snowflake : Wiz fixe une date limite de divulgation publique au 25 juillet 2026, trente jours après une résolution du 25 juin en vertu de la politique du programme, et a publié l’analyse le 17 août. Dans sa déclaration à CSO Online, Snowflake a indiqué que l’entreprise « apprécie le signalement responsable de Wiz » et qu’elle travaillait avec Wiz pour partager les enseignements avec l’industrie. Ni l’analyse de Wiz ni le rapport de The Hacker News ne comporte d’identifiant CVE, de score CVSS ou d’entrée dans le catalogue des vulnérabilités exploitées connues de la CISA ; la faille était une configuration de workflow dans un dépôt public, et non une bibliothèque distribuée, de sorte qu’elle n’a jamais été recensée dans une base de données de vulnérabilités selon la procédure habituelle.

Ce que le dossier établit, et ce qu’il n’établit pas

L’archive classe ceci comme une découverte de recherche plutôt qu’un événement de déploiement, avec une gravité élevée, une note de confiance de A, une implication de l’IA confirmée et un préjudice réel enregistré ; sa date, le 17 août 2026, est le jour où Wiz a publié, et l’incident lui-même s’étend du 18 au 23 juin. Le noyau établi est étroit et vérifiable : un workflow public a interpolé du texte contrôlé par l’attaquant dans une commande shell, sa condition de garde était comparée à une propriété qui est nulle sur cet événement, un jeton Jira se trouvait dans la même étape, un agent autonome l’a exploité, et Snowflake a fusionné un correctif et renouvelé le justificatif d’accès en moins d’un jour.

Les éléments qui relèvent de l’inférence plutôt que du constat documenté sont ceux que les récits informels tendent à aplanir. La documentation désigne Copilot Autofix comme coauteur de la pull request, et non comme auteur des lignes vulnérables ; le cadrage « IA contre IA » qui a porté le premier cycle médiatique a été en partie retiré par l’organisation de presse en quelques heures et réfuté par GitHub. La question de savoir si la revue IA de la pull request fusionnée a examiné jira_issue.yml reste une question factuelle ouverte, et non tranchée. Et l’ampleur de l’accès, bien que décrite en détail par Wiz, n’a pas fait l’objet d’un audit indépendant : rien n’a été rendu public, qu’il s’agisse d’autorisations Jira, d’une exécution de workflow ou d’un enregistrement d’audit.

Le modèle de correction est celui que les propres recommandations de GitHub préconisaient depuis juillet 2025 — transmettre les données de ticket non fiables dans une variable d'environnement et les passer à jq comme argument, plutôt que de les développer à l'intérieur d'un bloc run. Le commit fusionné de Snowflake fait exactement cela, et la gestion corrigée reste sur la branche par défaut. Pour quiconque lit le dossier comme un précédent, la conclusion durable porte sur l'attribution plutôt que sur l'injection : lorsqu'une pull request implique plusieurs humains et plusieurs agents, la ligne de co-auteur ne peut pas vous dire qui a écrit une ligne, et Wiz comme GitHub ont fini par le dire, chacun avec ses propres mots.