Comment l’attaque « Cryptographic Context Injection » peut exposer les conversations de Grok

Quand l’utilisateur demande un résumé ou une analyse, l’agent peut alors exécuter une routine de déchiffrement dans son environnement Python ou son bac à sable de code. Le texte obtenu revient ensuite au modèle sous la forme d’un résultat produit par un outil. C’est ce changement de contexte qui pose problème : un contenu contrôlé par l’attaquant, initialement présent sur une page non fiable, peut être interprété comme une sortie opérationnelle plus digne de confiance.

Adversa a indiqué avoir testé la méthode contre Grok 4.5 Fast sur grok.com. Une autre synthèse de ces essais fait état de 20 tentatives entre juin et août 2026, avec un taux de réussite de 40 %. Ce chiffre décrit l’environnement de test des chercheurs ; il ne signifie pas que chaque session Grok serait compromise.

Le déroulement de l’attaque

La chaîne décrite par les chercheurs se déroule en plusieurs étapes :

1. La page dissimule la charge utile. L’attaquant place sur une page apparemment ordinaire un contenu chiffré, du code ou des instructions de déchiffrement et le matériel nécessaire à cette opération. La méthode rapportée s’appuie notamment sur une dérivation de clé PBKDF2 et sur AES-256-GCM.

2. Le premier filtrage ne voit pas la commande. Les systèmes de défense peuvent inspecter le contenu visible de la page, mais l’instruction dangereuse est enfermée dans des données chiffrées. Le modèle ne peut donc pas directement interpréter cette commande lors de l’analyse initiale.

3. Grok effectue le déchiffrement. Pour répondre à la demande de résumé ou d’analyse, l’agent suit les indications de la page et exécute la procédure dans son environnement de code.

4. La commande réintègre le contexte de l’agent. Le texte déchiffré est présenté comme le résultat d’une opération effectuée par un outil. Cette étape crée un problème de provenance : le contenu de l’attaquant est passé d’une source externe non fiable à un contexte que l’agent peut traiter comme une sortie autorisée.

5. L’agent consulte les données accessibles dans la session. Dans la démonstration, les instructions déchiffrées demandaient notamment le nom de l’utilisateur, sa localisation approximative, son niveau d’abonnement et les invites ou éléments de conversation disponibles dans le contexte actif.

6. Une requête web transmet les informations. Grok ouvrait ensuite une URL contrôlée par l’attaquant et insérait les données collectées dans ses paramètres de requête. La démonstration rapportée s’est déroulée sans confirmation supplémentaire ni avertissement clairement visible.

Une nuance est importante : les éléments disponibles étayent l’accès aux invites et au contexte mis à la disposition de l’agent dans la session active. L’expression « historique complet des conversations » ne doit donc pas être automatiquement comprise comme un accès à toutes les conversations enregistrées dans le compte de l’utilisateur.

Quand la faille a-t-elle été signalée à xAI ?

Adversa affirme avoir signalé le problème à xAI via HackerOne le 3 juin 2026, puis avoir envoyé des relances de coordination les 4 et 10 août.

Au 19 août 2026, l’entreprise de cybersécurité disait n’avoir reçu aucune réponse substantielle et pouvoir encore reproduire l’attaque contre Grok. Les informations publiées à ce moment-là faisaient état de l’absence de correctif déployé, d’identifiant CVE public et de solution de contournement destinée aux utilisateurs.

Ce statut correspond au récit des chercheurs et des médias qui ont couvert la divulgation, et non à un avis de sécurité public de xAI. Les sources fournies ne démontrent pas non plus que cette technique ait été utilisée contre des utilisateurs réels en dehors des démonstrations de recherche.

Pourquoi le chiffrement peut aveugler les garde-fous

Les défenses classiques contre l’injection de prompt cherchent souvent des formulations suspectes dans les contenus récupérés par l’IA. La Cryptographic Context Injection déplace la commande dangereuse vers une étape ultérieure du traitement.

Le modèle n’a pas besoin de comprendre l’instruction malveillante lorsqu’il lit la page pour la première fois. Il lui suffit de suivre une consigne apparemment utile — par exemple exécuter une routine de déchiffrement — dans un environnement considéré comme fiable. La commande devient lisible seulement après cette exécution, alors que l’agent peut déjà avoir accès à un contexte privé et à des outils capables de naviguer ou d’effectuer des requêtes réseau.

La faille relève donc davantage de l’architecture des agents que d’un simple filtre de mots-clés. Lorsqu’un agent peut lire des contenus externes, exécuter du code, consulter des données de session et appeler des outils réseau, une instruction hostile peut transformer ces capacités en canal d’exfiltration.

Un risque qui dépasse le cas de Grok

La divulgation s’inscrit dans une série de recherches consacrées aux assistants capables d’agir sur des données et des outils sensibles.

• EchoLeak et Microsoft 365 Copilot : cette étude de cas a documenté une vulnérabilité d’injection de prompt sans clic dans Microsoft 365 Copilot, permettant l’exfiltration à distance de données via un e-mail spécialement conçu. Elle est suivie sous l’identifiant CVE-2025-32711.
• CoSnitch et Copilot Personal : des chercheurs de Varonis ont rapporté qu’une manipulation répétée du raisonnement de Copilot pouvait conduire l’assistant à envoyer des données sensibles vers un serveur externe et à empoisonner sa mémoire persistante.
• Les agents de programmation : les travaux TrustFall d’Adversa ont montré comment la configuration malveillante d’un dépôt pouvait amener un serveur MCP contrôlé par un attaquant à exécuter des commandes via des assistants tels que Claude Code, Gemini CLI, Cursor CLI et GitHub Copilot CLI.

Le point commun est que l’attaquant n’a pas forcément besoin de compromettre directement le modèle ou le système d’exploitation. Il fournit un contenu que l’agent est conçu pour lire, puis s’appuie sur les autorisations de celui-ci pour récupérer des informations, appeler des outils, modifier un état ou effectuer une requête réseau.

Quelles protections mettre en place ?

La démonstration d’Adversa suggère qu’un filtrage plus strict des prompts ne suffira pas. Les systèmes agentiques devraient notamment :

• séparer clairement la provenance des contenus, en distinguant techniquement et visuellement les pages web et sorties d’outils des instructions système et de l’état applicatif de confiance ;
• limiter l’exécution de code, afin qu’un contenu récupéré ne puisse pas déclencher librement un déchiffrement ou une autre opération ;
• appliquer le principe du moindre privilège, en restreignant le contexte privé accessible à l’agent ;
• exiger une validation explicite pour les actions sensibles, notamment les requêtes réseau contenant des données utilisateur ou conversationnelles ;
• contrôler les flux sortants, avec des listes de domaines autorisés, une inspection par proxy et des règles empêchant l’envoi de données vers des URL arbitraires ;
• surveiller les chaînes d’outils, par exemple la succession inhabituelle d’une récupération de page, d’une exécution de code, d’une extraction de contexte et d’une navigation externe.

La leçon centrale est simple : une sortie produite par un outil ne devient pas automatiquement fiable. Dans le cas rapporté de Grok, l’attaque aurait transformé une page web en chaîne de déchiffrement et d’exécution, avant d’utiliser les privilèges de l’agent pour faire sortir des informations privées de la session.