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.
Le mécanisme de l’attaque
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.
Plus de peur que de mal
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.
Vous avez lu 0 articles sur Numerama ce mois-ci
Tout le monde n'a pas les moyens de payer pour l'information.
C'est pourquoi nous maintenons notre journalisme ouvert à tous.
Mais si vous le pouvez,
voici trois bonnes raisons de soutenir notre travail :
- 1 Numerama+ contribue à offrir une expérience gratuite à tous les lecteurs de Numerama.
- 2 Vous profiterez d'une lecture sans publicité, de nombreuses fonctions avancées de lecture et des contenus exclusifs.
- 3 Aider Numerama dans sa mission : comprendre le présent pour anticiper l'avenir.
Si vous croyez en un web gratuit et à une information de qualité accessible au plus grand nombre, rejoignez Numerama+.
Toute l'actu tech en un clin d'œil
Ajoutez Numerama à votre écran d'accueil et restez connectés au futur !
Tous nos articles sont aussi sur notre profil Google : suivez-nous pour ne rien manquer !