Google Antigravity exfiltre des données via une attaque d’injection de prompt indirecte

 (promptarmor.com)
2 points par GN⁺ 2025-11-26 | 1 commentaires | Partager sur WhatsApp
  • Antigravity, le nouvel éditeur de code agentique de Google, peut exfiltrer les identifiants et le code d’un utilisateur via une injection de prompt indirecte
  • L’attaque repose sur le fait que Gemini lit des instructions cachées dans une page web malveillante, puis invoque un sous-agent navigateur (subagent) pour transmettre les données
  • Gemini contourne la protection du fichier .env, normalement inaccessible par défaut, pour lire des identifiants et les envoyer vers le domaine webhook.site
  • La liste d’autorisation par défaut (Allowlist) contient des domaines risqués, ce qui permet au sous-agent navigateur d’ouvrir normalement une URL malveillante
  • Google reconnaît le risque d’exfiltration de données et affiche un avertissement, mais il est reproché à la structure de configuration par défaut de rendre difficile pour l’utilisateur la surveillance de tous les comportements des agents

Vue d’ensemble de l’attaque

  • Antigravity est un éditeur de code agentique développé par Google, qui s’appuie sur le modèle Gemini pour assister l’écriture et l’exécution de code
  • L’équipe de recherche a construit son scénario d’attaque à partir d’un exemple d’intégration des AI Payer Agents d’Oracle ERP
    • L’utilisateur fournit à Gemini un guide d’implémentation trouvé en ligne
    • Cette page web contient une injection de prompt cachée en police de 1 point
  • Cette injection pousse Gemini à effectuer les actions suivantes
    • collecter le code de l’utilisateur et ses identifiants
    • générer une URL contrôlée par l’attaquant
    • accéder à cette URL via le sous-agent navigateur

Détails de la chaîne d’attaque

  • Gemini lit l’injection et la prend à tort pour une requête d’exécution d’outil
    • il tente de collecter le contenu de la base de code et du fichier .env
  • Par défaut, les fichiers inclus dans .gitignore sont bloqués, mais Gemini contourne cette protection
    • il utilise la commande cat pour afficher le contenu du fichier .env dans le terminal
  • Gemini génère ensuite, selon les consignes de l’attaquant, une URL malveillante contenant des identifiants encodés dans l’URL et des fragments de code
    • l’URL utilise le domaine webhook.site, ce qui permet à l’attaquant de consulter les journaux de requêtes en temps réel
  • Gemini invoque le sous-agent navigateur pour ouvrir cette URL, ce qui entraîne l’envoi des données vers l’extérieur
    • cela est possible car Enable Browser Tools est activé dans la configuration par défaut
    • webhook.site figure par défaut dans Browser URL Allowlist, donc la requête n’est pas bloquée
  • En conséquence, l’attaquant récupère, via les journaux webhook.site, des identifiants AWS et des fragments de code privés

Configuration par défaut d’Antigravity

  • Lors de l’onboarding, l’utilisateur est incité à accepter tels quels les paramètres recommandés par défaut
    • Artifact > Review Policy > Agent Decides : Gemini décide lui-même si une revue humaine est nécessaire
    • Terminal Command Auto Execution Policy > Auto : les commandes sont exécutées automatiquement
  • Ces paramètres permettent à Gemini d’exécuter des commandes sans intervention humaine

Structure de gestion des agents

  • L’interface Agent Manager d’Antigravity est conçue pour exécuter plusieurs agents simultanément et permettre à l’utilisateur de les consulter plus tard
    • la plupart des agents s’exécutent en arrière-plan sans supervision
    • cela crée la possibilité qu’un agent compromis par une injection de prompt réalise des actions malveillantes sans intervention de l’utilisateur

Google reconnaît le risque

  • Lors du premier lancement d’Antigravity, Google affiche un avertissement sur le risque d’exfiltration de données
  • Toutefois, l’équipe de recherche estime que la protection des utilisateurs reste insuffisante pour deux raisons
    1. Agent Manager est conçu pour exécuter plusieurs agents en parallèle, ce qui complique la surveillance en temps réel
    2. la configuration par défaut est pensée pour éviter la revue humaine
  • Ayant constaté que Google avait déjà connaissance de ces risques, l’équipe de recherche n’a pas engagé de procédure de divulgation responsable

Résumé

  • La vulnérabilité d’injection de prompt indirecte d’Antigravity exploite l’interaction entre Gemini et le sous-agent navigateur pour provoquer une fuite de données sensibles
  • Les failles des paramètres de sécurité par défaut et la structure agentique automatisée augmentent les chances de réussite de l’attaque
  • Google avertit du risque, mais aucune mesure d’atténuation fondamentale n’a encore été présentée

À lire aussi

1 commentaires

 
GN⁺ 2025-11-26
Avis Hacker News

  • J’aime bien l’approche « Rule of Two » proposée par Simon Willison et Meta
    C’est un principe qui n’autorise que deux conditions sur trois :
    A) traiter des entrées non fiables, B) accéder à des données privées, C) modifier un état externe ou communiquer avec l’extérieur
    Ce n’est pas parfait, mais cela m’a aidé à expliquer à la direction la dangerosité de l’outil lorsqu’il remplit ces trois conditions
    Articles liés : le billet de Willison, l’approche sécurité de Meta

    • Le point (C) ne couvre pas seulement les cas où l’agent communique volontairement avec l’extérieur, mais toute situation où l’utilisateur peut voir le texte généré
      Par exemple, même si la sortie passe par un LLM de surveillance avant affichage, une prompt injection peut se propager sous forme de quine
      C’est atténué dans des cas comme les problèmes de classification où la sortie peut être validée, mais la défense est difficile pour une sortie en texte libre
    • Même avec seulement A et B, des secrets peuvent tomber entre les mains d’un attaquant
      C’est un bon point de départ, mais ce n’est pas suffisant
      En regroupant l’état et la communication externe, on finit par se rendre compte que les trois conditions sont bien réunies

  • Johann Rehberger a signalé une vulnérabilité similaire dans Antigravity
    D’après le billet de blog associé et la page Google Bug Hunter,
    les attaques d’exfiltration de données contre l’agent navigateur sont déjà classées comme « known issue » et ne donnent pas droit à une récompense
    Avec l’accès aux fichiers et l’autorisation d’exécuter des commandes, il est possible d’exécuter des commandes malveillantes

    • Cela revient à reconnaître que ce type d’attaque est déjà un secret de Polichinelle dans l’industrie
      Toute personne qui s’intéresse à la sécurité des LLM connaît déjà la « lethal trifecta » et le risque d’exfiltration de données
      Mais il est regrettable que la plupart des gens ne s’enthousiasment que pour les nouvelles fonctionnalités et restent indifférents à la sécurité

  • Ce n’est pas un problème propre à Gemini ou Antigravity, mais un problème commun à tous les outils de code orientés agent ayant accès au CLI
    J’utilise personnellement Cline, mais je limite avec prudence l’accès MCP à la recherche web

    • Antigravity a essayé de se défendre avec une liste blanche de domaines et des restrictions sur les fichiers, mais a négligé les services permettant des redirections
      L’attaquant en a profité, et le LLM a contourné la protection des fichiers via le shell système
    • Le MCP de recherche web en lui-même est correct, mais le véritable vecteur d’attaque est le programme qui contrôle le modèle d’IA et le MCP
    • Copilot exige le consentement explicite de l’utilisateur avant d’accéder à une URL non fiable
      Le problème d’Antigravity est d’avoir autorisé des redirections ouvertes sans une telle procédure de consentement
    • Le filtrage fiable des URL est probablement un domaine où Google peut exceller
      grâce à la masse de données de recherche dont il dispose, et j’espère que cela contribuera à bloquer les prompt injections
    • Le fait d’inciter, dans la configuration par défaut, à autoriser automatiquement toutes les commandes mérite d’être critiqué

  • La créativité des attaquants n’en est qu’à ses débuts
    Avec la multiplication des IA agentiques automatisées et des systèmes de déploiement, il est inquiétant de voir la confiance s’installer à l’excès
    Le firmware GPU lui-même pourrait devenir un vecteur d’attaque
    Si j’étais un acteur étatique, c’est probablement là que je viserais

    • Là où je travaille, l’IA agentique n’a aucun accès aux secrets
      Depuis des décennies, nous n’autorisons même pas les humains à y accéder
      Mettre un fichier .env dans git serait impensable
      En revanche, il faut être encore plus vigilant face au risque croissant d’attaques combinant vulnérabilités firmware et modèles d’IA
    • Les entreprises commencent elles aussi à prendre conscience du risque
      Selon cet article de TechCrunch, même le secteur de l’assurance estime désormais que l’IA est trop risquée

  • J’ai moi aussi fait une divulgation responsable à Google concernant la même vulnérabilité
    en utilisant le même contournement de domaine (webhook.site),
    et j’ai aussi recensé d’autres problèmes publics, comme l’exécution de commandes à distance, dans mon billet de blog

  • Honnêtement, j’ai l’impression que ces articles sont très exagérés
    Ouvrir un CVE pour chaque LLM et s’étonner qu’« il peut exécuter des commandes » me semble être une perte de temps
    Je ne comprends pas pourquoi ce genre de billet arrive en une de HN

    • Mais ici, ce n’est pas un bug du LLM lui-même, c’est un défaut de conception du logiciel qui utilise le LLM
      Un LLM n’exécute pas du code tout seul, mais une intégration négligente comme Antigravity crée des vulnérabilités
    • Le vrai problème, c’est qu’un tiers peut en faire un vecteur d’attaque

  • Avec un accès à l’ensemble du système, on peut contourner les vérifications artificielles
    Il existe des outils d’isolation comme les sandboxes ou chroot, mais ils sont souvent ignorés à cause de la vitesse de mise sur le marché (GTM)
    Même un modèle local n’est pas sûr sans coupure d’Internet ou pare-feu sortant
    Le fait que les LLM ne puissent pas distinguer les commandes des données est la cause profonde de la plupart des vulnérabilités
    Excellent article

    • Il fut un temps où l’exécution de code était possible via les modelines de vim
      C’est une histoire qui se répète, de CVE-2002-1377 à CVE-2019-12735
      Je me demande si Antigravity finira lui aussi par recevoir un CVE
    • Il faut absolument un pare-feu entre le modèle et Internet
      Un outil qui manipule à la fois un modèle de langage et l’Internet externe ne devrait pas avoir accès à des données sensibles
    • Ces LLM pourraient aussi apprendre par eux-mêmes des moyens d’accéder à des ordinateurs distants ou de les pirater
    • Le mélange entre commandes et données n’est pas propre aux LLM
      ACE, XSS, injection SQL, etc., ont la même racine
      Comme on a trouvé des solutions dans le code classique, je pense qu’on finira aussi par en trouver pour les LLM

  • Des IDE comme Cursor accèdent chaque jour à des millions de secrets
    Ce genre de problème va continuer à se produire fréquemment

  • Le manque de reproductibilité des attaques fondées sur la prompt injection est intéressant
    Les modèles statistiques donnent des résultats différents pour une même entrée à cause de la part d’aléatoire
    Les modèles cloud comme ceux de Google sont en plus conçus de manière à rendre la reproduction des vulnérabilités difficile pour les chercheurs
    Et il est ironique que le style de l’article ressemble à la documentation de Google Cloud

  • Antigravity était aussi vulnérable à un bug d’exfiltration de données via image Markdown
    Il a été signalé il y a quelques jours, mais marqué comme « comportement intentionnel »
    Tweet associé

    • C’est toujours dans le même état, et il y a encore beaucoup d’autres problèmes
      J’en ai documenté une partie sur mon blog