- ▸ Le 27 mai 2026, PromptArmor frappe à la porte d'OpenAI
- ▸ Pourquoi cette faille de ChatGPT for Sheets déborde le cadre habituel
- ▸ Cinq ans d'avertissements publics sur l'injection indirecte
- ▸ Mécanique d'une exfiltration silencieuse dans ChatGPT for Sheets
PromptArmor a publié le 27 mai 2026 la démonstration d’une exfiltration silencieuse de workbooks Google Sheets via l’extension ChatGPT pour Google Sheets. Une simple injection indirecte de prompt suffit à déclencher la fuite. L’extension compte plus de 185 000 installations selon les données rapportées par la firme de sécurité. Trois mécanismes d’attaque, une riposte partielle d’OpenAI, une zone grise persistante sur la sandboxisation des modèles intégrés aux outils bureautiques.
Points clés 1. PromptArmor a publié le 27 mai 2026 la preuve d’une exfiltration de workbooks via injection indirecte de prompt sur l’extension ChatGPT for Google Sheets. 2. L’extension cumule plus de 185 000 installations, selon les chiffres relayés par la firme de sécurité. 3. Trois vecteurs d’attaque sont décrits : exfiltration de données, génération d’Apps Script malveillant, pop-up interactive de phishing. 4. OpenAI a retiré la capacité du modèle à générer du code Apps Script depuis l’extension et réévalue son approche du sandboxing, d’après PromptArmor. 5. La faille reproduit un schéma documenté depuis 2022 sur les LLM intégrés à des outils bureautiques, et illustre les limites des contre-mesures purement applicatives.
Le 27 mai 2026, PromptArmor frappe à la porte d’OpenAI
Le 27 mai 2026, l’équipe de chercheurs de PromptArmor met en ligne une démonstration vidéo et un rapport technique. Sur écran : un workbook Google Sheets ordinaire. L’utilisateur ouvre l’extension ChatGPT for Google Sheets, sollicite une analyse banale — résumer une colonne, reformater des dates. En arrière-plan, une cellule contenant un texte conçu pour le modèle reformule la requête. Le LLM exécute alors une commande étrangère à l’intention initiale de l’utilisateur. Le workbook est exfiltré, sa structure recopiée vers un domaine tiers, sans qu’aucun clic suspect n’ait été nécessaire. La formule « Apply edits automatically », citée par PromptArmor dans son rapport, devient le pivot de l’attaque : l’option qui automatise les modifications proposées par le modèle ouvre aussi la voie à des modifications dictées par un attaquant. La démonstration tient en moins de deux minutes. L’extension ne déclenche aucune alerte côté utilisateur.
Pourquoi cette faille de ChatGPT for Sheets déborde le cadre habituel
L’épisode dépasse le simple bug de sécurité. Il documente la collision entre deux logiques que les éditeurs de LLM peinent à concilier : la fluidité de l’expérience agentique et l’isolation stricte des données. Là où une injection directe suppose un utilisateur naïf qui colle un prompt malveillant, l’injection indirecte exploite la confiance accordée par défaut au contenu d’un fichier de travail. C’est l’ensemble de la promesse de l’IA bureautique intégrée qui se retrouve mise à l’épreuve par cette démonstration.
Cinq ans d’avertissements publics sur l’injection indirecte
L’injection indirecte de prompt n’a rien d’inédit. Le concept a été formalisé dès 2022 dans les premiers travaux académiques sur la sécurité des LLM, puis popularisé par Simon Willison, chercheur indépendant qui en documente publiquement les variantes sur son blog depuis cette époque. Les premières démonstrations visaient les assistants connectés à des boîtes mail : un courriel piégé pouvait amener un agent à divulguer le contenu d’autres correspondances. Le schéma est resté constant : un contenu apparemment passif — un document, une page web, une cellule — porte des instructions cachées que le modèle interprète comme légitimes au lieu de les traiter comme du simple texte.
D’après le référentiel publié par l’OWASP, la catégorie LLM01 du OWASP Top 10 pour les applications LLM est précisément consacrée à la prompt injection. Le document, mis à jour à plusieurs reprises depuis sa première version, classe l’injection indirecte comme le vecteur le plus difficile à mitiger par mesures purement applicatives. Les recommandations du référentiel insistent sur trois axes : le cloisonnement des privilèges, la séparation explicite entre données et instructions, et la mise en place d’une supervision humaine pour toute action à effet de bord — exécution de code, requête réseau, modification persistante de fichier.
Entre 2023 et 2026, plusieurs incidents publics ont jalonné la prise de conscience industrielle. Des attaques contre les assistants Copilot via des documents piégés ont été documentées dès 2023 par les équipes sécurité de Microsoft. Anthropic, dans ses publications publiques sur la sécurité de ses modèles, a explicitement reconnu qu’aucune technique connue n’éliminait totalement le risque d’injection indirecte. Plus récemment, les agents capables d’exécuter du code dans le navigateur ou de manipuler des fichiers utilisateurs sont devenus la cible privilégiée de chercheurs en sécurité offensive. La faille révélée par PromptArmor sur l’extension ChatGPT pour Google Sheets s’inscrit dans cette continuité documentaire. Elle vaut moins comme nouveauté technique que comme rappel structurel : la surface d’attaque s’élargit chaque fois qu’un LLM gagne une capacité d’agir directement sur des fichiers utilisateurs sans validation humaine intercalée.
Mécanique d’une exfiltration silencieuse dans ChatGPT for Sheets
Trois vecteurs distincts sont décrits dans le rapport de PromptArmor. Le premier — celui qui donne à l’affaire son titre — concerne la fuite directe de données. Une cellule contenant une instruction destinée au modèle peut amener celui-ci à concaténer le contenu du workbook dans une requête sortante vers un domaine externe. Le second vecteur passe par la génération d’Apps Script. Le code produit par le modèle, présenté à l’utilisateur comme un automatisme utile, s’exécute dans le contexte des permissions Google de la victime, avec accès aux feuilles partagées et aux services connectés au compte. Le troisième vecteur est plus surprenant : une pop-up interactive de phishing peut être affichée à l’utilisateur, mimant un dialogue système et collectant des informations d’authentification.
Le tableau ci-dessous synthétise les trois vecteurs, leur surface d’exécution et la conséquence directe pour l’utilisateur :
| Vecteur d’attaque | Surface d’exécution | Conséquence directe |
|---|---|---|
| Exfiltration de données | Requête réseau émise par l’extension | Workbook recopié vers un domaine tiers |
| Génération d’Apps Script | Code exécuté avec les permissions Google de la victime | Action persistante dans l’environnement Workspace |
| Pop-up interactive de phishing | Interface utilisateur de l’extension | Vol de credentials, escalade vers d’autres services |
Le point commun des trois vecteurs tient à la chaîne de confiance implicite. L’utilisateur sollicite une opération anodine — résumé, reformatage, calcul de moyenne. Le modèle traite l’intégralité de la zone visible comme du contenu pertinent à interpréter. Une cellule, masquée par formatage conditionnel ou simplement noyée parmi des données légitimes, suffit à modifier l’intention exécutée. La fonctionnalité « Apply edits automatically » mentionnée par PromptArmor amplifie le problème : elle court-circuite l’étape de validation humaine qui constituait jusqu’ici le dernier filet de sécurité.
Du point de vue technique, la faille reproduit la signature classique des injections indirectes. Le modèle ne dispose pas d’un mécanisme robuste pour distinguer une instruction provenant de l’utilisateur d’une instruction nichée dans les données qu’il analyse. Les recommandations actuelles — préfixe systémique renforcé, listes blanches de motifs, validation explicite de l’intention — n’éliminent pas la possibilité qu’un texte adversarial trompe le classifieur. C’est ce que rappelle PromptArmor en conclusion de son rapport : la mitigation passe par une refonte de l’architecture d’exécution, pas par un simple correctif de prompt.
Côté riposte, OpenAI a, selon les éléments rapportés par PromptArmor, supprimé la capacité du modèle à générer du code Apps Script depuis l’extension. L’éditeur indique également réévaluer son approche du sandboxing pour prévenir les attaques de prompt injection. Le calendrier de cette refonte n’a pas été communiqué publiquement. La suppression de la génération d’Apps Script ferme le deuxième vecteur le plus dangereux, mais ne traite pas l’injection indirecte à la racine. Une cellule piégée peut toujours, en théorie, déclencher une requête réseau exfiltrant des données.
ChatGPT for Sheets : 185 000 installations, une exposition mal cartographiée
L’extension ChatGPT for Google Sheets dépasse les 185 000 installations selon les chiffres relayés par PromptArmor. Le nombre paraît modeste rapporté aux centaines de millions d’utilisateurs actifs de Google Workspace, mais il masque une réalité plus problématique. Les extensions de productivité s’installent souvent au niveau du compte personnel, puis se propagent dans le contexte professionnel par usage quotidien. Une cellule piégée glissée dans un workbook partagé peut atteindre des collaborateurs qui n’ont jamais activement consenti à l’usage de l’extension sur leur propre compte.
La cartographie de l’exposition reste partielle. Aucune donnée publique ne permet de mesurer la proportion d’utilisateurs ayant activé l’option « Apply edits automatically », pivot opérationnel de l’attaque décrite. De même, la base d’utilisateurs entreprise — qui implique des workbooks à forte valeur — n’est pas distinguée des comptes personnels dans les compteurs d’installation accessibles. Les directions de la sécurité interrogées par la presse spécialisée sur des affaires similaires reconnaissent souvent ne pas inventorier précisément les extensions tierces utilisées par leurs équipes opérationnelles.
Pour les organisations soumises à des obligations de confidentialité — santé, finance, recherche industrielle, conseil — la question dépasse la simple fuite ponctuelle. Un workbook exfiltré peut contenir des données clients, des prévisions financières non publiées, des prototypes de calculs propriétaires. Le caractère silencieux de l’attaque empêche la détection en temps réel : aucune notification, aucune trace d’usage anormal côté utilisateur. La piste d’audit existe côté Google Workspace, mais elle ne devient lisible que si la défense connaît déjà l’indicateur à chercher dans le flux d’événements.
Sur le plan opérationnel, plusieurs équipes sécurité françaises consultées par la presse spécialisée IT recommandent depuis l’alerte une revue d’inventaire des extensions Workspace, l’interdiction temporaire d’« Apply edits automatically » dans les périmètres sensibles, et un audit du trafic sortant vers des domaines non listés. Aucune de ces mesures ne suffit isolément. La conjugaison des trois reste la pratique la plus défendable à court terme, en attendant une refonte annoncée mais non datée de la sandbox de ChatGPT for Sheets.
Voix divergentes sur le diagnostic
Tous les observateurs ne lisent pas la faille de la même manière. Pour une partie de la communauté sécurité, l’affaire PromptArmor relève d’un problème de design connu, dont les solutions existent mais ne sont pas appliquées par les éditeurs grand public. Cette lecture, défendue notamment par Simon Willison dans ses publications publiques sur la prompt injection, insiste sur la responsabilité des éditeurs à ne pas exposer d’actions à effet de bord — exécution de code, requêtes réseau, modifications de fichier — sans validation humaine explicite. Selon ce courant, l’erreur est moins technique que produit : on a câblé « Apply edits automatically » avant d’avoir résolu l’isolation.
Une seconde lecture, plus présente dans les rangs des éditeurs, considère que l’injection indirecte est un problème de recherche fondamentale, sans solution complète à ce jour. Anthropic, dans ses publications de recherche, a reconnu publiquement qu’aucune technique connue n’éliminait totalement le risque. Les contre-mesures déployées — détecteurs de prompts, filtres de sortie, sandboxing — réduisent la surface mais ne ferment pas le vecteur. Pour cette lecture, exiger une mitigation parfaite revient à interdire de fait toute intégration agentique aux outils bureautiques, et donc à renoncer à la promesse de l’IA assistant.
Une troisième position, défendue dans la communauté red-team, met l’accent sur la séparation des privilèges plutôt que sur la détection des prompts malveillants. Dans ce cadre, l’extension ne devrait jamais pouvoir initier une requête réseau vers un domaine non listé sans consentement explicite, et chaque action persistante — création d’un Apps Script, modification massive d’une feuille — devrait passer par un contrôle utilisateur. Cette approche évite le débat sans issue sur la robustesse du classifieur de prompts, en plaçant la sécurité au niveau de l’architecture d’exécution plutôt qu’à celui du contenu.
La réponse d’OpenAI, telle que rapportée par PromptArmor, mélange les trois lectures. La suppression de la génération d’Apps Script relève de la séparation des privilèges. La réévaluation du sandboxing, mentionnée par l’éditeur, va dans le même sens. La communication publique, en revanche, présente surtout des correctifs ponctuels, conformes à la lecture « problème de design corrigé au cas par cas ».
Vers une sandbox de second ordre pour ChatGPT for Sheets ?
À court terme, la question opérationnelle est claire : comment rendre l’extension utilisable sans rouvrir le vecteur ? Plusieurs pistes circulent dans la communauté. La première consiste à confiner l’exécution dans un environnement à privilèges réduits, où les requêtes réseau sortantes seraient limitées à une liste d’allow-list maintenue par l’éditeur. La seconde piste suppose une séparation explicite entre la zone d’analyse — où le modèle peut lire — et la zone d’action — où il peut écrire ou émettre une requête. Une troisième piste, déjà testée par d’autres acteurs, repose sur la signalisation systémique du contenu non fiable : tout texte issu d’une cellule serait étiqueté comme « donnée » et non comme « instruction » au niveau du préfixe envoyé au modèle.
Aucune de ces pistes n’est encore généralisée. Le calendrier d’OpenAI sur la refonte du sandboxing n’a pas été communiqué publiquement. Pour les utilisateurs, la question reste ouverte : à quel moment la fonctionnalité « Apply edits automatically » pourra-t-elle être réactivée sans rouvrir le vecteur d’attaque ? La réponse engage moins la sécurité de Google Sheets que celle, plus large, de toutes les extensions LLM bureautiques en circulation.
FAQ
Quelle est précisément la faille révélée par PromptArmor ?
Selon le rapport publié le 27 mai 2026 par PromptArmor, l’extension ChatGPT for Google Sheets est vulnérable à une injection indirecte de prompt. Un texte placé dans une cellule peut amener le modèle à exfiltrer le contenu d’un workbook, générer un Apps Script malveillant ou afficher une pop-up de phishing interactive. La fonctionnalité « Apply edits automatically » amplifie le risque en court-circuitant la validation humaine.
OpenAI a-t-il corrigé la vulnérabilité ?
D’après PromptArmor, OpenAI a supprimé la capacité du modèle à générer du code Apps Script depuis l’extension et indique réévaluer son approche du sandboxing. La communication publique ne précise pas de calendrier. Les correctifs déployés visent les vecteurs les plus directs, mais ne ferment pas le risque structurel d’injection indirecte, dont la mitigation reste un problème de recherche actif.
Que faire concrètement comme utilisateur ou comme DSI ?
À court terme, désactiver « Apply edits automatically », auditer l’inventaire des extensions Workspace, contrôler le trafic sortant vers des domaines non listés. À moyen terme, restreindre l’usage de l’extension aux périmètres non sensibles tant qu’un nouveau modèle de sandbox n’aura pas été déployé. Aucune mesure isolée n’est suffisante : la défense doit combiner inventaire, contrôle réseau et restriction fonctionnelle.
Cette faille concerne-t-elle d’autres extensions LLM ?
Le mécanisme — injection indirecte via contenu utilisateur — n’est pas spécifique à ChatGPT for Google Sheets. Il a été documenté depuis 2022 sur les assistants connectés à des boîtes mail, des navigateurs ou des plateformes documentaires. La leçon dépasse l’extension visée : toute intégration agentique d’un LLM à un outil bureautique partage la même classe de vulnérabilité tant que l’isolation données/instructions n’est pas garantie au niveau architectural.
Sources
- PromptArmor, « ChatGPT for Google Sheets Exfiltrates Workbooks », 27 mai 2026 — promptarmor.com
- OWASP Foundation, « OWASP Top 10 for LLM Applications », LLM01 — Prompt Injection, référentiel public mis à jour
- Simon Willison, publications publiques sur la prompt injection indirecte depuis 2022 (simonwillison.net)
- Anthropic, recherches publiques sur les limites des contre-mesures à l’injection indirecte de prompt
- Microsoft, incidents documentés sur Copilot via documents piégés (2023-2024)
