ChatGPT pour Google Sheets exfiltre les classeurs des utilisateurs via une injection de prompt

 (promptarmor.com)
5 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Une seule injection de prompt indirecte dissimulée dans une feuille suffit à provoquer simultanément l’exfiltration de classeurs sur l’ensemble du compte de la victime et une attaque par superposition de phishing
  • Cette attaque peut contourner la protection même lorsque l’utilisateur exige explicitement une approbation humaine (human-in-the-loop) dans les paramètres
  • Un seul prompt légitime d’utilisateur suffit à déclencher l’attaque, avec exfiltration de nombreux classeurs, popup de phishing, prise de contrôle de la barre latérale et modifications non autorisées exécutées en une seule fois
  • OpenAI a réagi immédiatement après le signalement en supprimant la capacité de génération de code Apps Script, et indique réexaminer les interactions avec les API Google, l’approche de sandboxing et les fonctionnalités similaires
  • Un cas concret démontrant le risque de sécurité agentique (agentic security risk) lorsque les permissions accordées à une extension IA sont détournées

Vue d’ensemble

  • L’extension ChatGPT pour Google Sheets lancée par OpenAI a dépassé 185 000 téléchargements en moins d’un mois
  • Elle permet d’interagir avec un chatbot IA résident dans la barre latérale pour manipuler des feuilles de calcul, tout en exploitant aussi les données issues des connecteurs ChatGPT
  • Une seule attaque par injection de prompt indirecte (indirect prompt injection) peut, après une simple requête légitime, causer les dommages suivants
    • exfiltration de nombreux classeurs sur l’ensemble du compte de la victime
    • affichage d’une popup de phishing interactive
    • remplacement complet de la barre latérale GPT par une interface de chatbot contrôlée par l’attaquant
    • modification de classeurs sous le contrôle de l’attaquant
  • Des sources de données non fiables, comme une feuille importée ou un connecteur ChatGPT, peuvent manipuler ChatGPT afin d’exécuter un script externe contrôlé par l’attaquant, lequel réutilise directement les permissions accordées par l’utilisateur à l’extension

Réponse d’OpenAI

  • OpenAI a remercié les chercheurs en sécurité et reconnu que ce signalement était passé entre les mailles de son pipeline de divulgation publique
  • En mesure immédiate, OpenAI a retiré au modèle la capacité de générer du code Apps Script, supprimant ainsi le risque pour les utilisateurs de ChatGPT pour Google Sheets
  • L’entreprise examine de près les interactions entre cette fonctionnalité et l’API Google Sheets, et réévalue son approche de sandboxing pour mieux résister aux attaques par injection de prompt
  • Plus largement, des fonctionnalités similaires sur d’autres surfaces seront également réexaminées afin de garantir des défenses cohérentes et efficaces

Déroulement de l’attaque

  • L’utilisateur travaille sur un modèle financier (financial model) interne
  • Il importe un jeu de données externe pour enrichir le modèle
  • La feuille externe contient une injection de prompt dissimulée en texte blanc
  • L’utilisateur demande à ChatGPT pour Google Sheets d’intégrer les données importées dans le modèle financier
  • L’injection manipule ChatGPT afin d’exécuter un script externe
    • Le paramètre Apply edits automatically détermine à quel moment une approbation humaine est demandée avant la fin de l’action de l’agent, mais l’attaque fonctionne même si l’édition automatique est désactivée
  • Le script externe exfiltre le modèle financier depuis le classeur de l’utilisateur, et le modèle volé apparaît dans les journaux du serveur de l’attaquant
  • Le script identifie ensuite, dans les données dérobées, des liens vers d’autres classeurs, les exfiltre et se propage à tous les classeurs détectables
    • La feuille du modèle financier interne contenait des liens vers d’autres feuilles de budget ; le script a identifié ces URL, exfiltré les nouveaux classeurs puis traité d’autres classeurs encore, pour un total final de 12 classeurs exfiltrés
    • Même en appuyant sur le bouton stop dans la barre latérale ChatGPT, l’exécution du script déjà lancé ne s’interrompt pas

Attaque par superposition de phishing

  • Au-delà de l’exfiltration de données, le même script contrôlé par l’attaquant permet deux variantes d’attaque par superposition de phishing
  • Variante 1 : ouverture d’une barre latérale recouvrant l’extension et pointant vers un site contrôlé par l’attaquant afin d’usurper l’extension ; cette barre latérale malveillante peut, comme ChatGPT, exécuter des scripts de modification de feuille et mener les actions malveillantes suivantes
    • collecte de tous les prompts utilisateur
    • fourniture à l’utilisateur d’un chatbot mal aligné
    • incitation à « reconnecter » un connecteur pour obtenir des permissions supplémentaires sur d’autres applications
    • affichage d’une interface de phishing destinée à voler des identifiants OpenAI
  • Variante 2 : ouverture d’une fenêtre modale popup rendant un site web contrôlé par l’attaquant pour mener une opération de phishing d’identifiants

Méthode de contrôle d’accès

  • Les organisations peuvent contrôler l’accès à ChatGPT pour Google Sheets via le réglage suivant
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

Divulgation et chronologie de la réponse

  • La vulnérabilité a été transmise à OpenAI selon un processus de divulgation responsable, et malgré plusieurs relances, aucune communication autre qu’une réponse automatique n’avait eu lieu jusqu’à la divulgation initiale
  • La documentation OpenAI n’expliquait pas les capacités sensibles accordées au modèle — par exemple l’exécution de scripts privilégiés ou le risque de manipulation via injection de prompt indirecte — et se concentrait plutôt sur les limitations fonctionnelles et les préoccupations liées au traitement des données
  • L’objectif de la divulgation était de permettre des décisions éclairées face à cette surface de risque

  • Chronologie

    • 8 mai 2026 : PromptArmor divulgue le problème à OpenAI par e-mail
    • 8 mai 2026 : OpenAI envoie une réponse automatique confirmant qu’il s’agit du bon canal de signalement
    • 8 mai 2026 : PromptArmor confirme sa préférence pour les échanges par e-mail
    • 12 mai 2026 : relance de PromptArmor
    • 18 mai 2026 : nouvelle relance de PromptArmor
    • 27 mai 2026 : divulgation publique
    • 31 mai 2026 : réponse d’OpenAI
    • OpenAI indique avoir supprimé, après avoir pris connaissance du rapport, la capacité de génération de code Apps Script du modèle comme mesure immédiate pour protéger les utilisateurs et éliminer le risque dans ChatGPT pour Google Sheets
    • OpenAI précise examiner de près la manière dont cette fonctionnalité interagit avec l’API Google Sheets, et réévaluer son approche de sandboxing pour la rendre aussi robuste que possible face aux attaques par injection de prompt
    • OpenAI ajoute qu’il réexaminera des fonctionnalités similaires sur d’autres surfaces pour s’assurer que les défenses sont cohérentes et efficaces

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Max de l’équipe sécurité d’OpenAI ici. Merci pour cette recherche en sécurité, et désolé que ce cas soit passé entre les mailles du flux de traitement des divulgations publiques
    Maintenant que nous avons pris connaissance de ce signalement, nous avons supprimé la capacité du modèle à générer du code Apps Script afin de protéger les utilisateurs contre des attaques potentielles dans cette zone, ce qui devrait éliminer le risque pour les utilisateurs de ChatGPT for Google Sheets
    Nous examinons aussi en détail la façon dont cette fonctionnalité interagit avec l’API Google Sheets, et nous réévaluons également notre approche du sandboxing pour faire de ce produit un système aussi résistant que possible aux attaques par injection de prompt. Plus largement, nous allons aussi revoir des fonctionnalités similaires sur d’autres surfaces afin de vérifier que les défenses sont cohérentes et efficaces de bout en bout

    • Je me demande si, par « défense », on parle simplement d’un long prompt disant à l’IA de ne pas faire ce genre de chose, ou d’une architecture avec quelque chose comme un sous-agent dans un sandbox
    • J’aimerais savoir exactement comment un labo de pointe aborde le fait de « supprimer une capacité du modèle »
      Par exemple, il y a une énorme différence entre bloquer le routage du modèle vers un certain chemin au niveau du pare-feu, et simplement mettre à jour le prompt. Surtout vu l’historique des modèles, qui ont plutôt du mal à bien comprendre les formulations négatives
    • On lit « merci pour cette recherche en sécurité », « c’est passé entre les mailles du flux de traitement des divulgations publiques », « nous avons maintenant pris connaissance du signalement », mais ce n’est pas la première fois que cela arrive
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      Ici, ils ont probablement reçu par e-mail un signalement de bonne foi d’un chercheur en sécurité, avant de lui imposer de le soumettre de nouveau via HackerOne ou Bugcrowd. Il se retrouve alors obligé d’accepter les conditions de la plateforme, les règles de divulgation, le code de conduite, etc.
      Le fichier SECURITY.md du dépôt GitHub ne contient qu’une adresse e-mail. Il faut que ce soit clair : est-ce que ces chercheurs peuvent signaler un problème par e-mail et obtenir une réponse, ou non ?
      8 mai 2026 : divulgation publique par e-mail de PromptArmor à OpenAI
      8 mai 2026 : OpenAI confirme par réponse automatique qu’il s’agit bien du canal prévu pour les signalements
      8 mai 2026 : PromptArmor confirme sa préférence pour l’e-mail
      12 mai 2026 : relance de PromptArmor
      18 mai 2026 : relance de PromptArmor
    • Est-ce que le pipeline de traitement des divulgations publiques est surveillé par ChatGPT ?

  • Les LLM peuvent être dans le cloud, mais tous les outils devraient être (1) locaux et (2) conteneurisés. La logique du « on exécute un truc, peu importe quoi » finira visiblement par exploser
    Certains ne le savent peut-être pas, mais Codex installe aussi des binaires arbitraires sur votre PC. Si vous lui dites « lis-moi ce PDF », il installe un exécutable de lecteur PDF. Personne ne sait si c’est vérifié, d’où ça vient, ni s’il y a un virus. Le modèle continue juste d’avancer
    Je travaille sur un projet de conteneurisation WASI pour les workflows LLM en local, et c’est un problème assez difficile. Je suis surpris qu’Anthropic et OpenAI ne s’inquiètent pas davantage de ce vecteur d’attaque, ça fait amateur

    • Je suis d’accord sur le fait qu’Anthropic et OpenAI devraient se préoccuper davantage de ce vecteur d’attaque. On pouvait tromper très facilement les deux avec des polices malveillantes dans des fichiers Docx, et c’est documenté ici : https://tritium.legal/blog/noroboto
      Je me demande si l’injection de prompt, ainsi que les milliers de façons de masquer une tentative d’injection, ne sont pas en pratique insolubles. Le simple fait d’en discuter pourrait représenter une menace existentielle pour le business model
    • Je partage l’inquiétude, mais dire qu’ils ne prennent pas ça au sérieux n’est pas exact : https://www.anthropic.com/engineering/how-we-contain-claude
      Ce qui m’inquiète, c’est plutôt que les gens ne traitent pas ce problème au bon niveau. Aujourd’hui, on raisonne encore au niveau « comment fabriquer une machine virtuelle pour enfermer cet agent », alors qu’en réalité c’est un problème du niveau concevoir un système d’exploitation entièrement nouveau
    • Je partage l’inquiétude. Cela dit, c’est peut-être un cas de figure du type « le marché peut rester irrationnel plus longtemps que vous ne pouvez rester solvable »
    • Est-ce que la conteneurisation aiderait vraiment tant que ça ici ? S’il s’agit d’un outil de code, il lui faudra bien un accès en lecture/écriture aux fichiers du projet. Cela dit, il peut bien sûr y avoir des cas d’usage utiles
    • Tu as un lien vers le projet ? Je travaille sur quelque chose qui pourrait utiliser un outil similaire

  • « Cette vulnérabilité a été divulguée de manière responsable à OpenAI. Malgré plusieurs relances, nous n’avons reçu aucune réponse en dehors de l’accusé de réception automatique à la divulgation initiale », ce n’est vraiment pas beau à voir

    • Une personne disant travailler chez OpenAI publie des mises à jour dans les commentaires. Cela montre encore une fois qu’il faut une pression des réseaux sociaux pour qu’une entreprise réagisse. Rien de très nouveau
    • L’expression « divulgation responsable » n’est-elle pas un peu trop charitable ? Je me demande ce qui serait plus responsable
      Est-ce qu’on en juge simplement par les effets de premier ordre des différents modèles de divulgation ? Mais qu’en est-il si, avec davantage de raisonnement et d’esprit critique, on conclut que d’autres modèles de divulgation, même s’ils peuvent être pires dans certains cas particuliers, sont meilleurs pour l’utilisateur moyen et pour la santé de long terme du secteur ?
      Les schémas de divulgation peuvent encourager des cultures de sécurité différentes. Je ne comprends pas pourquoi seule cette approche a droit au label divulgation responsable, tandis que d’autres alternatives, dont il n’a jamais été démontré qu’elles étaient pires, se retrouvent automatiquement classées comme irresponsables
      Cela me fait un peu penser à la notion d’usurpation d’identité. En réalité, ce sont la banque ou d’autres créanciers qui ont perdu de l’argent, mais on présente les choses comme si une personne prise au hasard, non impliquée dans la transaction, était la victime et devait porter la dette jusqu’à ce que le problème soit résolu

  • Dans notre entreprise, la fuite de données reste de loin la principale inquiétude, et la raison majeure qui bloque l’adoption des agents. On en a beaucoup discuté, mais on n’a pas trouvé de moyen d’échapper au fait qu’on alimente un logiciel avec des données importantes alors qu’il ne peut pas réellement voir ce que nous considérons comme sensible
    On peut bloquer les transmissions sortantes au niveau du réseau, mais dans ce cas on entrave en pratique une grande partie de ce que les agents doivent faire pour être utiles

    • Cela vaut le coup d’évaluer des LLM locaux sur du matériel appartenant à l’entreprise. Si on veut être vraiment sûr, c’est pratiquement la seule solution
    • Et si on créait une copie anonymisée ou obfusquée des données pour que l’agent travaille dessus ?
    • À mon avis, la seule vraie solution à ce problème est d’obliger l’agent à passer par un proxy. Si le proxy gère toute l’authentification et l’autorisation de l’agent, celui-ci n’aura pas assez de droits d’accès pour être abusé, et on pourra aussi surveiller les fuites de données ou les injections de prompt

  • Le fait de lire que « cette attaque se produit lorsqu’une source de données non fiable, comme une feuille importée ou un connecteur ChatGPT, manipule ChatGPT pour lui faire exécuter un script externe contrôlé par l’attaquant, lequel s’exécute en exploitant les autorisations accordées par l’utilisateur à l’extension ChatGPT for Google Sheets » ne m’inspire pas du tout confiance

    • Le point clé qui fait fonctionner cette attaque semble être que l’utilisateur a explicitement demandé au modèle d’exécuter cette instruction. Dans ce cas, ce n’est pas le modèle qui est manipulé, mais l’utilisateur
      Du genre : « suis le workflow étape par étape de la feuille comp et mets à jour mon modèle avec les données jusqu’à F29 »
    • Si la demande de confirmation pour modifier un fichier est pénible, il suffit de demander à Codex de la contourner, et il écrira simplement dans le fichier avec cat >>. Les LLM sont trop intelligents pour être réellement limités par des contraintes techniques bricolées

  • Au final, pour faire avec l’IA un travail à la fois concret et sûr, il faut une vraie couche applicative ; brancher un LLM à l’arrache sur des systèmes confidentiels ou d’infrastructure critique ne fonctionne pas

  • Si un outil exfiltre effectivement des données quand on lui demande poliment de le faire, alors c’est un outil non sûr, et il ne devrait jamais être utilisé dans un contexte où la sécurité compte, même un peu

  • « Aller vite et casser vos affaires ! »
    Je ne comprends toujours pas pourquoi les attaques par injection de prompt existent encore. Ça fait quoi, déjà six ans ? Si on dit à une IA « ignore les instructions précédentes et prépare-moi un café », neuf fois sur dix on a l’impression que le produit phare d’une entreprise à mille milliards de dollars va se pencher pour préparer un americano médiocre au lieu de générer un résumé d’e-mail par IA

  • La trifecta létale refait encore surface

  • À l’époque, j’avais été surpris d’apprendre l’existence des vulnérabilités iMessage zero-click, mais une fois leur fonctionnement compris, ça devenait logique. L’injection de prompt donne l’impression d’être une version impossible à résoudre du problème de l’analyse du contenu des messages