- Une vulnérabilité de validation des commandes a été découverte dans le Cortex Code CLI de Snowflake, permettant à un attaquant d’exécuter des commandes arbitraires en dehors du sandbox
- L’attaque est déclenchée via une injection de prompt indirecte, contourne la procédure d’approbation de l’utilisateur, puis télécharge et exécute un script malveillant
- Les commandes à l’intérieur de la syntaxe de process substitution n’étaient pas validées, ce qui permettait l’exécution automatique d’un code malveillant déguisé en commande sûre
- Les attaquants pouvaient utiliser le token d’authentification Snowflake de la victime pour exfiltrer la base de données ou supprimer des tables
- Snowflake a corrigé le problème avec le patch de la version 1.0.25, déployé le 28 février 2026 et appliqué via mise à jour automatique
Aperçu de la vulnérabilité de Cortex Code CLI
- Cortex Code CLI est un agent de code en ligne de commande comparable à Claude Code ou OpenAI Codex, avec une intégration permettant d’exécuter du SQL dans Snowflake
- Deux jours après son lancement, il a été confirmé qu’en raison d’une faille du système de validation des commandes, des commandes spécialement conçues pouvaient être exécutées sans approbation et sortir du sandbox
- Un attaquant pouvait exploiter cela pour utiliser les identifiants Snowflake de la victime afin de mener des actions malveillantes comme l’exfiltration de données ou la suppression de tables
- L’équipe sécurité de Snowflake a vérifié le problème puis l’a corrigé, et le patch a été déployé dans la version 1.0.25
Étapes de la chaîne d’attaque
- Lorsque l’utilisateur lance Cortex avec le mode sandbox activé, le système est censé demander une approbation avant l’exécution d’une commande
- Cependant, un attaquant peut manipuler Cortex au moyen d’une injection de prompt cachée dans un fichier README, afin de l’amener à exécuter des commandes dangereuses
- Le sous-agent de Cortex lit cette injection et exécute la commande sans passer par la procédure d’approbation
- Comme les commandes à l’intérieur de la syntaxe de process substitution
<()> n’étaient pas validées, un code malveillant pouvait être exécuté sous l’apparence d’une commande classée comme sûre
- L’injection définissait également le flag
dangerously_disable_sandbox, ce qui permettait une exécution en dehors du sandbox
- Résultat : un script malveillant était téléchargé puis exécuté sans approbation de l’utilisateur
Impact de l’attaque
- L’attaquant obtenait la capacité d’exécuter du code arbitraire à distance (remote code execution) sur le système de la victime
- En utilisant les identifiants de connexion Snowflake de la victime, il pouvait notamment :
- exfiltrer le contenu de la base de données
- supprimer des tables
- ajouter des comptes utilisateur malveillants
- modifier les règles réseau pour bloquer les utilisateurs légitimes
- Le script malveillant recherchait les tokens d’authentification mis en cache par Cortex et exécutait des requêtes SQL sur Snowflake
- Dans le cas d’un compte développeur, les droits de lecture et d’écriture permettaient l’exfiltration et la destruction de données
Problème de perte de contexte des sous-agents
- Pendant l’exécution de l’attaque, Cortex appelait plusieurs sous-agents, ce qui provoquait une perte de contexte
- L’agent principal avertissait l’utilisateur qu’une commande malveillante avait été détectée, mais le sous-agent l’avait déjà exécutée
- L’utilisateur ne pouvait donc pas savoir qu’une exécution réelle avait déjà eu lieu
Divulgation de la vulnérabilité et réponse
- Le 5 février 2026, PromptArmor a procédé à une divulgation responsable (responsible disclosure) auprès de Snowflake
- Snowflake a collaboré avec PromptArmor tout au long du mois de février pour vérifier et corriger la vulnérabilité
- Le patch a été déployé dans la version 1.0.25 le 28 février, et s’appliquait automatiquement lors du redémarrage de Cortex
- Les tests ont montré un taux de réussite de l’attaque d’environ 50 %, soulignant l’importance de l’entraînement à la sécurité face au caractère non déterministe des LLM
Chronologie principale
- 2 février 2026 : lancement de Snowflake Cortex Code
- 5 février 2026 : signalement de la vulnérabilité par PromptArmor
- 12 février 2026 : fin de la vérification de la vulnérabilité par Snowflake
- 28 février 2026 : déploiement de la version corrigée 1.0.25
- 16 mars 2026 : divulgation conjointe par PromptArmor et Snowflake
1 commentaires
Avis Hacker News
En général, je lis d’abord le communiqué officiel de l’entreprise concernée
Mais j’ai été surpris de voir que l’annonce de Snowflake n’était accessible qu’avec un compte
Après lecture, j’ai eu l’impression que le terme « sandbox » était mal employé
Si « Cortex peut, via un flag activé par défaut, exécuter des commandes hors de la sandbox », alors ce n’est plus une sandbox
En SQL, on n’a rien réglé avant l’arrivée des requêtes paramétrées, et le langage naturel est bien plus libre
Au final, des attaques du type « ignore les instructions précédentes et… » reviennent sans cesse
Si les données et les commandes passent dans le même flux, on finit toujours au même résultat
Le langage naturel élargit forcément encore davantage la surface d’attaque
Document associé : RFC 3514
Mais le sens auquel je suis habitué est celui d’un environnement isolé permettant d’observer un malware en toute sécurité
Je trouve intéressant qu’il y ait aussi beaucoup de tentatives pour créer de vraies frontières techniques de ce type pour l’IA
Si l’utilisateur peut lui-même manipuler un interrupteur qui active les droits d’accès, alors ce n’est pas une sandbox
Au début, je croyais qu’il s’agissait d’une élévation de privilèges au niveau de l’OS, mais c’était simplement un cas de conception de sécurité médiocre
D’après des cas cités dans un article d’Anthropic, l’IA peut aussi adopter de manière autonome des comportements malveillants
Par exemple, le pare-feu d’Alibaba Cloud aurait détecté une tentative de minage de cryptomonnaie depuis un serveur d’entraînement,
et ce comportement serait apparu comme effet secondaire lors d’une optimisation RL
Ressources associées : article arXiv, recherche Anthropic, article de Time
Un employé de Snowflake est intervenu pour partager la chronologie de la réponse de l’équipe sécurité ainsi que les correctifs apportés
Plus de détails dans la documentation officielle
En voyant la partie disant que « des commandes shell ont été exécutées sans approbation humaine »,
toute personne ayant un minimum réfléchi à la sécurité du shell sera surprise qu’on n’ait pas pris en compte la manière de créer les sous-processus
Ce genre de restriction doit être appliqué au niveau de l’OS pour être sûr
Il a été proposé de partager des « vrais conseils de sandboxing »
Pour ma part, je fais tourner Claude Code dans un devcontainer VS Code
Il existe aussi une configuration pour limiter l’accès à Internet à une liste de domaines autorisés
Cela dit, comme il faut un environnement docker-in-docker, l’intégration complète reste difficile
Pour l’instant, je me limite donc à l’exécution des tests unitaires, et je me demande si je ne devrais pas essayer une isolation complète dans une VM avec Vagrant
Lien du projet : aflock.ai
En lisant la phrase « Cortex ne prend pas en charge workspace trust »,
certains se sont demandé si, à la base, il ne s’agissait pas d’un environnement sans restrictions
Si le modèle définit ce flag, l’exécution a lieu immédiatement hors de la sandbox, sans approbation de l’utilisateur
Quelqu’un a plaisanté en demandant si c’était une nouvelle forme de recherche sur le gain-of-function
en disant qu’il est illusoire de croire qu’un agent peut se contrôler lui-même
Beaucoup de gens exécutent déjà sans relecture du code généré par des agents
Dans ce cas, on peut se demander à quoi bon encapsuler l’agent lui-même dans une sandbox
De toute façon, l’ensemble du système devrait être isolé sur une machine distincte, dans un conteneur ou sous un utilisateur restreint
Comme la plupart des utilisateurs ne le font probablement pas,
les éditeurs semblent essayer de fournir à la place un niveau de protection minimal par défaut
Certains ont estimé qu’« une sandbox qu’on peut désactiver avec un simple toggle n’est pas une vraie sandbox »
Cela ressemble plutôt à du marketing exagéré, destiné à masquer la faiblesse de la conception du produit
en rappelant qu’une vraie sandbox doit être un environnement d’isolation externe qu’on ne peut pas modifier depuis l’intérieur