Antigravity find_by_name : quand un appel d'outil natif saute par-dessus le Secure Mode

What is this?

Le 20 avril 2026, le chercheur Dan Lisichkin (Pillar Security) a publié Prompt Injection leads to RCE and Sandbox Escape in Antigravity, le compte-rendu public d’une vulnérabilité dans Google Antigravity — l’IDE agentique de Google, où des agents pilotés par Gemini pilotent un éditeur de code et un shell sur la machine du développeur. The Hacker News et CSO Online ont repris la divulgation le 21 avril 2026, avec une couverture de suivi par Dark Reading et CyberScoop, et une note de recherche du Cloud Security Alliance Labs.

Le défaut est petit et précis : le paramètre Pattern de l’outil find_by_name d’Antigravity était transmis sans assainissement au binaire fd sous-jacent. Une valeur Pattern commençant par - est interprétée par fd comme un drapeau plutôt qu’un terme de recherche, et le drapeau -X (exec-batch) transforme la recherche de fichier en exécution de commandes arbitraires. Combiné à la capacité normale de l’agent à créer des fichiers dans l’espace de travail, cette primitive donne une exécution de code à distance sous le propre Secure Mode d’Antigravity, le sandbox le plus strict de l’IDE.

Pillar a signalé le bug à Google le 7 janvier 2026. Google l’a accepté le 24 janvier 2026, marqué comme corrigé le 28 février 2026 et versé une prime VRP le 26 mars 2026 avant la divulgation publique du 20 avril 2026. Le délai de divulgation responsable de 90 jours est largement écoulé ; la vulnérabilité est corrigée.

How it works

find_by_name est documenté comme un mince wrapper de commodité autour de fd, l’alternative rapide à find. Il accepte un objet JSON avec des champs comme Pattern, Extensions, SearchDirectory, MaxDepth. À l’intérieur de l’outil, Pattern est interpolé dans la ligne de commande fd sans terminateur d’argument (--) et sans filtrage des tirets de tête de style shell. Deux ingrédients de la chaîne d’attaque sont alors visibles :

1. fd traite Pattern comme un drapeau dès qu’il commence par -.
2. fd -X <bin> exécute <bin> pour chaque fichier correspondant, en passant les noms de fichiers correspondants comme arguments.

# Structure conceptuelle — illustrative uniquement, tirée de l'avis Pillar.
# C'est la classe de bug publiée et corrigée ; rien ici n'est nouveau.

# 1) L'injection de prompt indirecte arrive dans Antigravity via
#    un fichier non fiable (README d'un repo cloné, commentaire en source).
#    Le texte injecté demande à l'agent de :
#
#    - créer un fichier dans l'espace de travail (action autorisée)
#    - puis appeler find_by_name avec Pattern commençant par "-Xsh"
#
# 2) L'appel d'outil natif s'exécute AVANT que le Secure Mode n'évalue
#    quoi que ce soit, parce que l'agent classifie find_by_name comme
#    un outil natif, pas une commande shell.
#
# 3) fd reçoit un "drapeau" au lieu d'un motif, bascule en mode
#    exec-batch et exécute le fichier déposé via sh.
#
# Structure de payload concrète tirée de l'avis :
#   Pattern: "-Xsh"
#   Extensions: ["orange"]            # correspond au fichier déposé
#   SearchDirectory: <espace de travail>
#
# Résultat : chaque fichier a.orange déposé est passé à sh, exécutant
# tout ce que l'agent a été instruit d'écrire plus tôt dans l'espace de travail.

Le détail qui fait de cette vulnérabilité plus qu’un bug générique d’injection d’arguments est le contournement du Secure Mode. Le Secure Mode d’Antigravity est documenté comme bloquant les écritures hors espace de travail, restreignant la sortie réseau et forçant les commandes shell à s’exécuter sandboxées. Aucun de ces contrôles ne se déclenche ici, parce que find_by_name est dispatché comme un outil natif, pas une commande shell. La frontière de sécurité que le Secure Mode applique se trouve derrière une vérification que l’agent n’atteint jamais dans ce chemin de code. L’avis confirme que l’exploit a réussi avec Secure Mode activé et Auto Execution désactivé — la configuration la plus restrictive publiée de l’IDE.

Le caractère espace est échappé sur le chemin Pattern, donc le drapeau injecté ne peut pas être suivi d’arguments en ligne. Pillar contourne cela en déposant d’abord la charge utile comme un fichier séparé — une action autorisée — puis en appelant find_by_name dont la correspondance passe ce fichier à sh. Deux opérations ordinaires chaînées à travers un outil ordinaire produisent du RCE.

Why it matters

L’affaire Antigravity est l’exemple canonique 2026 de l’injection de paramètre d’outil dans les IDE agentiques. Trois observations méritent d’être comprises même si vous n’utilisez pas Antigravity.

Premièrement, l’injection de prompt n’est plus la partie intéressante de la chaîne. Le texte injecté tient sur une ligne. Le travail est fait par la conception de l’outil : un paramètre qui traverse la frontière de « données contrôlées par le LLM » à « argv passé à un utilitaire shell » sans terminateur d’argument. Le CVE-2026-22708 de Cursor, également documenté par Pillar, suit la même forme. Tout comme la classe de CVE du transport STDIO de MCP d’Anthropic documentée en avril. La surface d’attaque en 2026 est l’écart entre « le LLM passe des données à un outil » et « l’outil interprète ces données comme une structure de commande ».

Deuxièmement, la classification « outil natif » est un concept porteur que peu d’utilisateurs comprennent. Le modèle de menace d’Antigravity supposait que verrouiller les commandes shell derrière le Secure Mode couvrirait les opérations dangereuses. En pratique, un outil qui enveloppe fd fait les mêmes choses que sh ferait, simplement par un chemin de code différent. La distinction shell vs natif a du sens à l’intérieur de l’agent, est invisible pour le système d’exploitation, et inutile comme frontière de sécurité.

Troisièmement, le chemin d’injection indirecte signifie que l’utilisateur n’a pas besoin d’être trompé par quoi que ce soit d’élaboré. Cloner un dépôt, ouvrir un fichier, demander à l’agent de le résumer — n’importe lequel suffit pour que les instructions intégrées atterrissent dans le contexte de l’agent. L’exploit publié n’a besoin d’aucune authentification, d’aucun compte compromis, d’aucune extension malveillante.

Defenses

Le bug lui-même est corrigé dans Antigravity. La classe ne l’est pas.

La première défense, à la fois au niveau de l’éditeur de l’IDE et à l’intérieur de toute pile d’agent maison, est de terminer les arguments à la frontière de l’outil. Chaque fois qu’une chaîne fournie par un LLM est interpolée dans une ligne de commande, préfixez par --, validez par rapport à une liste blanche de caractères appropriés au paramètre (les motifs de noms de fichiers ne commencent pas par -), et rejetez l’entrée qui contient des drapeaux de style shell ou de la traversée de chemin. Le correctif ici tient en une ligne de validation d’entrée. Le bug existe parce que cette ligne manquait.

La deuxième défense est de classifier les appels d’outils par leur effet, pas par leur wrapper. Si un outil peut, en fin de compte, exécuter un binaire, lancer un script ou écrire en dehors de l’espace de travail, il appartient derrière la même frontière de sandbox qu’une commande shell brute, peu importe que le code de l’agent l’étiquette « natif ». Le Secure Mode dans Antigravity devrait — et le fera, après le patch — évaluer find_by_name de la même manière qu’il évalue run_in_terminal. Les équipes applicatives qui exploitent leurs propres agents devraient auditer chaque outil sur la même propriété.

La troisième défense est l’isolation de processus au niveau du runtime de l’agent. Exécutez l’agent dans un conteneur ou une VM sans montage du système de fichiers hôte au-delà du dépôt de travail, sans réseau sortant sauf requis explicitement pour une tâche unique, et avec une identité séparée du compte développeur. Le chemin d’évasion de l’exploit Antigravity incluait l’écriture dans ~/.zshrc et le lancement d’applications natives ; un runtime isolé réduit ce rayon d’impact à un sandbox jetable.

La quatrième défense est de traiter les dépôts non fiables comme du code non fiable, pas comme des données. Tirer un dépôt public dans un IDE agentique est l’équivalent 2026 d’ouvrir une pièce jointe d’un expéditeur inconnu. Ouvrez-le d’abord à froid si nécessaire, avec l’agent désactivé ou en lecture seule, et exécutez les outils de revue de sécurité sur l’arborescence avant qu’aucune fonctionnalité agentique ne la touche.

Une étape de durcissement séparée : abonnez-vous à la cascade. L’avis Antigravity fait référence au CVE-2026-22708 de Cursor, à la classe MCP STDIO d’Anthropic et à la chaîne RCE Semantic Kernel de Microsoft (CVE-2026-25592, CVE-2026-26030). Chaque framework qui laisse un modèle appeler un outil avec des arguments sous-validés est un candidat pour la prochaine entrée. Suivre les flux de divulgation d’OX Security, Pillar et CSA coûte moins cher qu’attendre votre propre incident.

Status

Élément	Référence	Date	Notes
Avis Pillar Security	« Prompt Injection leads to RCE and Sandbox Escape in Antigravity »	2026-04-20	Divulgation principale ; PoC complet avec Secure Mode activé
Couverture presse	The Hacker News, CSO Online, Dark Reading, CyberScoop	2026-04-21	Corroboration indépendante
Note de recherche CSA Labs	Agentic IDE prompt injection sandbox escape	2026-04	Cadrage en classe systémique d’IDE agentique
Signalement initial à Google	Pillar → Google AI VRP	2026-01-07	Accusé de réception le jour même
Correctif déployé	Google Antigravity	2026-02-28	52 jours après le signalement
Prime VRP	Google	2026-03-26	Catégorie spécifique IA
Avis liés	Cursor CVE-2026-22708, Anthropic MCP STDIO, Semantic Kernel CVE-2026-25592 / CVE-2026-26030	2026-02 à 2026-04	Même schéma racine : paramètres d’outil sous-validés atteignant un shell

L’histoire Antigravity est courte et mérite d’être conservée. Un seul -- manquant a fait la différence entre une recherche de fichier et une exécution de code à distance. Chaque IDE agentique sur le marché aujourd’hui possède des dizaines d’outils de classe find_by_name, et la plupart ont été conçus avant que « l’injection de paramètre d’outil » ne soit une expression que quiconque utilisait. Auditez en conséquence.