Grok : une page web piégée pourrait lui faire voler des données de conversation

Une simple demande de résumé pourrait-elle suffire à exposer l’historique d’une conversation avec Grok ? C’est le scénario présenté par le chercheur Rony Utevsky, d’Adversa AI, qui a signalé une technique d’injection indirecte sans clic visant l’agent web de Grok. L’utilisateur doit seulement demander à Grok d’analyser ou de résumer une page contrôlée par un attaquant. Celle-ci dissimule ses instructions sous forme de données chiffrées, puis amène l’agent à les déchiffrer et à les traiter dans son propre environnement d’exécution.

L’impact décrit est potentiellement grave : la charge utile déchiffrée pourrait demander à l’agent de récupérer des informations privées de session et de les intégrer à une requête envoyée vers un serveur externe. Les éléments disponibles proviennent principalement de la divulgation d’Adversa AI et de reprises dans la presse. Il faut donc parler d’une preuve de concept rapportée, et non d’une faille confirmée publiquement par xAI.

Ce que change la « Cryptographic Context Injection »

Les défenses classiques contre l’injection de prompts cherchent souvent des instructions suspectes dans le texte visible. La technique décrite par Adversa tente de contourner cette étape en plaçant les instructions malveillantes dans une page sous forme de texte chiffré.

La page contiendrait notamment une charge utile JSON chiffrée en AES-256-GCM, des éléments permettant de dériver la clé et des consignes incitant Grok à exécuter du code de déchiffrement dans son environnement Python ou sandbox.

Il ne s’agit pas de casser AES. Le chiffrement sert ici de moyen d’évasion : un filtre de contenu peut ne voir qu’une suite opaque de caractères, tandis que l’agent dispose des outils nécessaires pour transformer cette suite en instructions exploitables plus tard dans le processus.

La nuance est essentielle. Filtrer le texte visible ne revient pas à contrôler ce qu’un agent est autorisé à faire après avoir analysé, déchiffré ou exécuté des données provenant d’une source non fiable.

Le déroulement de l’attaque rapportée

La chaîne décrite comporte quatre étapes principales :

1. Une page malveillante semble ordinaire. La victime demande à Grok d’en résumer ou d’en analyser le contenu.
2. La page fournit des données chiffrées et des indications de déchiffrement. Selon Adversa, la charge utile utilise AES-256-GCM avec une clé dérivée par PBKDF2, ce qui maintient les instructions principales sous une forme opaque lors de l’inspection initiale.
3. Grok exécute la logique de déchiffrement. Les instructions en clair apparaîtraient alors par l’intermédiaire du code ou des outils exécutés par l’agent, plutôt que sous la forme évidente d’un texte présent sur la page. Adversa affirme que Grok traite ensuite ce résultat comme un contexte fiable.
4. La charge utile détourne l’action suivante de l’agent. Les instructions demanderaient à Grok de récupérer des informations privées de session, puis de les insérer dans une URL que l’agent ouvre afin de transmettre les données à un serveur contrôlé par l’attaquant.

Dans sa preuve de concept, Adversa indique avoir obtenu le nom de l’utilisateur, sa localisation approximative, son niveau d’abonnement, ses prompts et son historique de conversation. L’entreprise affirme que le transfert s’est effectué sans avertissement visible ni demande de confirmation dans sa démonstration.

Le véritable périmètre de sécurité : l’environnement d’exécution

Le problème ne tient donc pas uniquement au fait que Grok ait reçu un prompt malveillant. Selon le scénario rapporté, des données issues d’une page non fiable auraient franchi plusieurs frontières de confiance :

• le contenu de la page est devenu un contexte exécutable ou susceptible de déclencher une action ;
• le résultat déchiffré a été considéré comme plus fiable que ne le justifiait son origine ;
• des informations privées de conversation ou de session ont été rendues accessibles à la chaîne d’attaque ;
• l’agent a pu utiliser une requête externe pour faire sortir ces données de la session.

Une instruction ne devient pas fiable simplement parce qu’elle provient d’un programme de déchiffrement, d’un outil ou d’un résultat intermédiaire de l’environnement d’exécution. La provenance doit rester attachée aux données malgré ces transformations. Sans cette garantie, le parsing, l’exécution de code, la recherche ou les sorties d’outils peuvent donner une apparence d’autorité à du contenu contrôlé par un attaquant.

Divulgation et état du correctif

D’après le récit d’Adversa, Rony Utevsky a signalé le problème à xAI et via HackerOne le 3 juin 2026. Dans sa divulgation du 20 août, Adversa affirme que la faille n’était toujours pas corrigée depuis plus de deux mois, malgré plusieurs relances.

Les informations disponibles au moment de la divulgation ne mentionnaient ni réponse publique de xAI, ni identifiant CVE, ni calendrier de correction. Cet état des lieux repose sur la divulgation du chercheur et les articles publiés à la même période ; aucune déclaration publique indépendante de xAI confirmant la découverte ou sa remédiation n’est fournie ici.

Les corrections à privilégier

Les recommandations d’Adversa portent sur l’environnement d’exécution de l’agent, plutôt que sur l’ajout de nouveaux filtres de mots-clés :

• Conserver la provenance et les marqueurs de contamination. Les données provenant d’une page web doivent rester non fiables après leur parsing, leur déchiffrement, leur exécution ou leur passage par un outil.
• Séparer les données de l’autorité. Un contenu non fiable, ainsi que les valeurs qui en dérivent, ne devrait pas pouvoir appeler des outils privilégiés, accéder au contexte privé d’une conversation ou définir des paramètres sensibles.
• Restreindre le trafic sortant. Des listes d’autorisation, des contrôles de destination et des politiques de prévention des fuites doivent s’appliquer avant l’envoi de données vers un nouveau point de terminaison externe.
• Exiger un consentement compréhensible. Toute action impliquant du contexte privé ou une transmission externe devrait demander une confirmation claire, précisant quelles données vont quitter la session et vers quelle destination.
• Appliquer le principe du moindre privilège. Une tâche de résumé ne devrait pas donner automatiquement accès à l’intégralité de l’historique de discussion, aux métadonnées du profil, à l’exécution de code ou à un accès réseau sans restriction.

Ces mesures s’attaquent à la combinaison dangereuse d’une entrée non fiable, d’un contexte privé, de l’exécution de code et d’outils capables d’agir. Le comportement de refus du modèle ne peut pas, à lui seul, constituer une frontière de sécurité suffisante.

Un problème qui rappelle d’autres attaques contre les agents IA

Le cas de Grok s’inscrit dans une tendance plus large : l’attaquant manipule le contenu que l’agent doit traiter, puis exploite les autorisations légitimes dont celui-ci dispose.

La faille EchoLeak de Microsoft 365 Copilot a été décrite comme une injection de prompt sans clic : un e-mail spécialement conçu pouvait permettre l’exfiltration à distance et sans authentification de données accessibles à l’assistant. Une étude universitaire l’identifie sous le numéro CVE-2025-32711.

Des travaux distincts sur Copilot Personal ont décrit la chaîne CoSnitch, dans laquelle un lien spécialement conçu pouvait déclencher l’exécution d’un prompt et l’exfiltration de données provenant d’applications connectées. Les chercheurs indiquent que Microsoft a déployé des correctifs le 18 août 2026.

Les agents de programmation présentent un risque comparable, mais via les dépôts de code plutôt que les pages web. Adversa a rapporté que des dépôts malveillants pouvaient exploiter les mécanismes de confiance et de configuration de plusieurs assistants, dont Claude Code, Cursor CLI, Gemini CLI et Copilot CLI, afin d’exécuter des serveurs MCP contrôlés par un attaquant avec des privilèges potentiellement étendus. Une autre analyse d’Adversa décrit un contournement de règles basé sur de longues chaînes de commandes shell, avec un risque de vol d’identifiants ou de secrets.

Le vecteur diffère — e-mail, URL, document, dépôt, page chiffrée ou intégration d’outil — mais la leçon architecturale reste la même : un agent ne doit pas transformer un contenu contrôlé par un attaquant en autorisation de lire des données confidentielles ou de déclencher une action externe.

L’enjeu plus large pour la sécurité de l’IA

La Cryptographic Context Injection montre pourquoi la sécurité des agents ne peut pas se limiter à l’analyse du texte qui entre initialement dans la fenêtre de contexte. Un agent peut rencontrer des instructions après un déchiffrement, une recherche, un parsing, une exécution de code, un accès mémoire ou un autre appel d’outil.

Si chaque transformation efface l’origine des données, l’attaquant peut exploiter l’écart entre ce que le système classe comme non fiable et ce que l’environnement d’exécution finit par considérer comme digne de confiance.

Pour les utilisateurs, la prudence est de mise lorsqu’un agent ayant accès à des conversations privées ou à des outils doit traiter une page web, un document, un lien ou un dépôt inconnu. Pour les développeurs, la priorité est plus structurelle : imposer des frontières de confiance dans l’environnement d’exécution, limiter l’accès au contexte sensible, contraindre les paramètres des outils, contrôler les sorties réseau et rendre les actions à fort impact visibles et confirmables.

La technique rapportée contre Grok doit donc être comprise non comme une « rupture d’AES », mais comme un avertissement sur le blanchiment d’autorité. Le chiffrement peut cacher une instruction à un filtre ; seul un environnement d’exécution trop permissif peut ensuite transformer cette instruction dissimulée en action de vol de données.