Copilot Autofix a ouvert une injection de shell dans le pipeline CI/CD de Snowflake

Un correctif de sécurité rédigé par Copilot Autofix de GitHub et fusionné dans un dépôt Snowflake le 18 juin 2026 a supprimé un modèle d’entrée désinfectée et a laissé le pipeline CI/CD de l’entreprise ouvert à l’injection de commandes, et cinq jours plus tard, un agent de recherche IA autonome a découvert la faille, l’a exploitée et a extrait des identifiants Jira fonctionnels d’un exécuteur GitHub Actions, Wiz Research disclosed on 17 août 2026.

La vulnérabilité se trouvait dans jira_issue.yml, un workflow GitHub Actions dans snowflakedb/snowflake-connector-net, le dépôt public du connecteur de données .NET de Snowflake. Le workflow s’exécutait chaque fois que quelqu’un ouvrait une issue GitHub et interpolait le titre de l’issue (texte entièrement contrôlé par la personne qui la crée) directement dans un script shell. Comme le déclencheur était issues: opened, n’importe quel compte GitHub sur Internet pouvait y accéder sans authentification.

Le « Red Agent » de Wiz, un outil de recherche en sécurité autonome fonctionnant via le programme de bug bounty HackerOne de Snowflake, a signalé le workflow, construit un exploit fonctionnel et exfiltré un jeton API Jira depuis l’environnement de l’exécuteur. Snowflake a corrigé le workflow le même jour où il a reçu le rapport, le 23 juin 2026, a renouvelé les identifiants le jour suivant, et a indiqué à Wiz que ses journaux d’audit ne montraient aucun autre acteur ayant accédé aux systèmes exposés pendant la fenêtre de cinq jours.

Le « Autofix » a supprimé le désinfecteur

Le commit qui a introduit le modèle injectable a été introduit via PR #1218, “SNOW-2069227: Update jira workflows”, fusionné le 18 juin 2026. L’historique de la pull request montre un auteur humain travaillant sur l’automatisation Jira depuis août 2025 — et, à mi‑parcours, un commit co‑authored par Copilot Autofix powered by AI, le bot GitHub Advanced Security qui génère des correctifs suggérés pour les alertes d’analyse de code.

La suggestion IA a modifié la façon dont le workflow traitait le titre de l’issue. Le code existant faisait passer le titre via une variable env: et construisait sa charge JSON avec jq --arg, un modèle qui empêche le texte non fiable d’atteindre le shell. Le remplacement proposé a abandonné cela au profit d’une expansion directe de chaîne:

“ run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g") “

L’échappement sed s’exécute après que le moteur de modèles de GitHub a déjà substitué le titre dans le script. Une apostrophe dans le titre rompt l’encapsulation echo '...', et tout ce qui suit s’exécute comme du shell. La documentation de GitHub sur Copilot Autofix décrit la fonctionnalité comme générant « une seule correction suggérée pour une alerte, que vous examinez et appliquez vous‑même » — l’étape de révision est celle où celle‑ci a été validée.

Le workflow comportait également une condition de garde qui semblait restreindre qui pouvait le déclencher:

“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “

Lors des événements d’issue, github.event.pull_request est toujours nul, donc la comparaison est toujours vraie. Tous les utilisateurs GitHub franchissaient la porte.

Un agent de chaque côté de l’exploit

La première tentative d’exfiltration du Red Agent a échoué. Sa charge utile utilisait le caractère de commentaire # pour absorber le reste de la ligne injectée, mais le commentaire a également consommé la parenthèse fermante de TITLE=$(...), et l’exécuteur a renvoyé une erreur de syntaxe bash au lieu de s’exécuter. Selon le rapport de Wiz, l’agent a analysé l’erreur, a réécrit sa charge pour fermer le bloc shell avec ; echo ', et a réessayé.

La charge utile fonctionnelle, livrée comme titre d’issue, a encodé en base64 les variables d’environnement JIRA_API_TOKEN, JIRA_USER_EMAIL et JIRA_BASE_URL de l’exécuteur et les a envoyées à un écouteur hors bande via curl. Le rappel est arrivé d’un exécuteur GitHub Actions hébergé sur Azure en quelques secondes.

Le jeton récupéré s’est authentifié en tant que qa@snowflake.net sur snowflakecomputing.atlassian.net, avec un accès en lecture à travers les projets d’ingénierie, de conformité sécurité et de suivi des programmes de bug bounty de Snowflake.

La remédiation de Snowflake, fusionnée dans PR #1402 le 23 juin 2026, a restauré la variable sûre env: et le modèle d’analyse jq --arg. Le jeton Jira a été révoqué et renouvelé le 24 juin 2026. Wiz a déclaré avoir supprimé en toute sécurité toutes les données consultées pendant son test de preuve de concept.

“Snowflake apprécie le signalement responsable de Wiz et la collaboration autour de ces découvertes via notre programme de divulgation de vulnérabilités et de bug bounty, HackerOne,” a déclaré l’entreprise dans un communiqué publié avec le rapport de Wiz. “La divulgation a été reçue le 23 juin 2026, elle a été immédiatement étudiée et corrigée, et notre enquête n’a trouvé aucune preuve d’accès non autorisé.”

Ce que montre la fenêtre de cinq jours

La divulgation s’inscrit au cœur d’un schéma documenté: les changements assistés par l’IA traversent la révision plus rapidement que les hypothèses de sécurité qui les entourent. Les journaux d’audit de Snowflake sont ce qui rend cet incident lisible: ils permettent à l’entreprise d’affirmer, et à Wiz de confirmer, que la fenêtre d’exposition n’a généré aucun accès de tiers. L’analyse des journaux d’audit de Snowflake a confirmé qu’aucun tiers externe n’a accédé au point de terminaison pendant la fenêtre de cinq jours.

La chronologie compresse également une séquence que l’industrie a longtemps considérée comme hypothétique. Un assistant de codage a supprimé un modèle de défense mis en place spécifiquement pour prévenir les injections de shell, parce que l’assistant n’avait aucune trace de la raison d’existence de ce modèle. Un agent offensif a ensuite trouvé et exploité le résultat en quelques jours, auto‑corrigeant son exploit à partir de la sortie d’erreur en direct. Le côté exploit s’est exécuté sans humain au clavier ; du côté du codage, l’IA a généré la modification mais un humain a appliqué la suggestion et l’a fusionnée — ce qui correspond exactement à l’étape de révision qui a échoué.

Le rapport de Wiz recommande que les pull requests générées par l’IA passent par la même analyse statique que le code humain, que les équipes raccourcissent la durée de vie des identifiants pour correspondre aux vitesses de découverte automatisées, et que les garde‑fous empêchent les agents de remplacer les analyseurs structurés par une interpolation directe de chaînes. Check Point a déplacé l’inspection des prompts pour le trafic IA dans les pare‑feux d’entreprise cet été, et Unite.AI a couvré les échappées de sandbox d’agents et les systèmes agentiques atteignant de réelles cibles de production à mesure que le côté offensif mûrit. L’incident Snowflake est la même histoire racontée depuis l’intérieur d’un pipeline CI: la vulnérabilité a été active pendant cinq jours, et la seule raison pour laquelle il apparaît comme une étude de cas plutôt qu’une notification de violation est de savoir quel agent est arrivé le premier.