Comment un agent IA a trouvé une faille, corrigé son propre bug, et fini par accéder au Jira de Snowflake

Un dépôt public, une automatisation Jira, et un chasseur de failles autonome. Voici les ingrédients de cette affaire.

La cible ? Snowflake, l’entreprise cloud spécialisée dans le stockage et l’analyse de données, qui héberge comme beaucoup d’éditeurs certains de ses connecteurs open source sur des dépôts publics GitHub.

Parmi eux, « snowflake-connector-net », qui embarque un workflow GitHub Actions, comprenez un script d’automatisation qui s’exécute à chaque événement défini sur le dépôt. Le mécanisme est chargé d’une tâche a priori anodine, à chaque nouvelle issue ouverte, il transforme automatiquement son titre en ticket Jira interne.

Une brique d’automatisation invisible pour la plupart des utilisateurs, mais qui a suffi aux chercheurs de Wiz et à leur agent IA offensif d’accéder aux tickets internes de l’entreprise, comme le raconte l’article de blog publié le 17 août 2026.

Tout serait parti d’une modification effectuée le 18 juin, dans la manière dont le titre d’une issue GitHub est transmis au script de création du ticket Jira. Avant, le code isolait proprement cette donnée avant de l’utiliser. Après, le titre est directement injecté dans une commande shell, sans neutraliser les caractères spéciaux. Une régression que ni la relecture par GitHub Copilot (crédité comme co-auteur de la modification), ni le scan automatisé de GitHub Advanced Security n’ont détectée, alors même que ce dernier avait bien analysé le fichier en question.

Pire, une condition censée restreindre le déclenchement du workflow aux seuls comptes autorisés reposait sur la comparaison d’une variable systématiquement vide dans ce contexte. N’importe quel compte GitHub pouvait ainsi le déclencher en ouvrant une simple issue publique.

Wiz a testé la faille en rédigeant un titre d’issue conçu pour détourner le script vers l’envoi des identifiants Jira à un serveur externe.

Première tentative ratée : le caractère utilisé pour tronquer la commande a provoqué une erreur de syntaxe. Plutôt que de s’arrêter là, l’agent IA a analysé seul cette erreur, ajusté son attaque pour refermer correctement le bloc shell. La deuxième tentative est un succès et en quelques secondes, Wiz recevait un jeton d’authentification Jira, associé à un compte donnant accès en lecture aux projets d’ingénierie, de conformité sécurité et de suivi du bug bounty de Snowflake.

Bonne nouvelle, une analyse forensique menée sur les journaux d’audit a permis à Snowflake de confirmer qu’aucun tiers n’avait accédé aux données exposées durant les cinq jours où la faille est restée active.

Wiz a signalé la vulnérabilité à Snowflake via HackerOne le 23 juin 2026. L’entreprise a corrigé le workflow incriminé dans la journée, en restaurant le mécanisme de neutralisation des entrées supprimé par la PR fautive, puis a révoqué et renouvelé le jeton Jira compromis dès le lendemain.

Votre VPN préféré n'est pas celui que vous croyez Meilleur VPN 2026 : le Comparatif complet de Numerama Retrouvez notre comparateur pour choisir le meilleur VPN Vous avez lu 0 articles sur Numerama ce mois-ci

Tout le monde n'a pas les moyens de payer pour l'information.