Attaque Zero-Click Grok : le vol de conversations par injection de prompt chiffré qui inquiète

Le 22 août 2026, une attaque par injection de prompt chiffré, baptisée « Cryptographic Context Injection », a été rendue publique par les chercheurs d’Adversa AI. Cette vulnérabilité zero-click cible l’assistant Grok de xAI et permet à un attaquant de dérober l’intégralité de l’historique des conversations, le nom, la localisation et le type d’abonnement d’un utilisateur. Le vecteur d’attaque est d’une simplicité redoutable : il suffit que la victime demande à Grok de résumer une page web contrôlée par l’attaquant. Cette technique représente une rupture majeure dans l’évolution des menaces pesant sur les grands modèles de langage (LLM). Elle exploite la capacité des agents IA à interagir avec le web et à exécuter du code Python, transformant les fonctionnalités les plus avancées de l’assistant en vecteurs de compromission. Pour les RSSI et DPO français, cette attaque zero-click Grok soulève des questions fondamentales sur la sécurité des agents IA, la conformité RGPD et la confiance à accorder à ces outils dans un contexte professionnel.

Comment l’attaque zero-click Grok contourne les défenses des LLM

L’attaque « Cryptographic Context Injection » se distingue des injections de prompt traditionnelles par l’utilisation du chiffrement comme vecteur d’évasion. Historiquement, les injections de prompt se limitaient à des instructions adverses en clair (type « ignorez les instructions précédentes ») ou encodées (Base64, Unicode). Les modèles modernes, entraînés à résister à ces tentatives, ont poussé les attaquants à innover. L’étape suivante fut le token smuggling et le payload splitting. Jamais, jusqu’à présent, un chiffrement fort utilisant des algorithmes cryptographiques standards n’avait été utilisé pour duper le modèle de manière aussi élégante.

Le sandbox Python : un environnement d’exécution détourné

Grok 4.5 Fast, comme de nombreux LLM récents, intègre un sandbox Python pour effectuer des calculs complexes, analyser des données ou exécuter du code provenant de pages web. L’attaquant exploite cette fonctionnalité de manière ingénieuse. La page web soumise à l’assistant contient trois éléments distincts :

1. Un objet JSON chiffré contenant le payload malveillant.
2. Une clé de déchiffrement dérivée via PBKDF2.
3. Une instruction en clair demandant à l’IA de déchiffrer les données à l’aide du sandbox Python.

Le choix des algorithmes cryptographiques est crucial. Le PBKDF2 (Password-Based Key Derivation Function 2) rend le cassage par force brute extrêmement coûteux en calcul. Le AES-256-GCM (Galois/Counter Mode) assure à la fois la confidentialité et l’intégrité des données. Si le payload est modifié, le déchiffrement échoue, évitant ainsi une détection par corruption de données.

« Le LLM ne peut pas déchiffrer le payload à partir de ses seuls poids de modèle. Il doit exécuter du code Python. Une fois le déchiffrement effectué, le résultat n’est pas traité comme un contenu web, mais comme le résultat fiable d’un calcul interne. » - Adversa AI

Cette citation des chercheurs résume le cœur de la vulnérabilité : la rupture de la frontière de confiance (trust boundary failure). Dans une application classique, les données entrantes (input utilisateur, contenu web) sont strictement séparées des commandes système. Dans un agent IA, le résultat de l’exécution d’un outil (ici, le sandbox Python) est considéré comme faisant partie intégrante de l’état cognitif du modèle, au même titre qu’une instruction système. Le payload déchiffré hérite donc d’un niveau de confiance maximal, lui permettant de modifier le comportement de l’agent de manière invisible.

Le scénario d’exfiltration en quatre étapes

Le payload déchiffré exploite cette confiance pour orchestrer une exfiltration de données en silence. Voici la chaîne d’attaque complète telle que documentée par les chercheurs :

# Chaîne d'attaque « Cryptographic Context Injection »
1. [WEB] Agent charge la page malveillante et exécute le code JavaScript
2. [CODE] Sandbox Python exécute le déchiffrement AES-256-GCM
3. [CONTEXT] Résultat du code promu en instruction système de confiance
4. [MEMORY] Lecture de l'historique complet et du profil utilisateur
5. [NETWORK] Navigation vers URL d'exfiltration via le navigateur intégré

L’ensemble de la chaîne s’est déroulée sans aucune boîte de dialogue de confirmation, ni aucun avertissement visible pour la victime, sur Grok 4.5 Fast accessible via grok.com. Le taux de réussite sur une vingtaine de tentatives réalisées entre juin et août 2026 était d’environ 40 %. Les échecs étaient systématiquement dus à des erreurs de déchiffrement (notamment des timeouts du sandbox Python), et jamais à une barrière de sécurité ou à un mécanisme de détection d’injection de prompt. Les chercheurs ont confirmé pouvoir rejouer l’attaque avec succès le 19 août 2026, soit plus de deux mois après le signalement initial.

Un problème systémique qui dépasse le cas Grok

Adversa AI ne s’est pas arrêtée à xAI. Les chercheurs ont également démontré une attaque similaire contre Google Gemini en mode Deep Thinking. Dans cette variante, le payload chiffré contenait un faux traceback Python, un faux callback de politique de sécurité et un préfixe de raisonnement à la première personne. Cette démonstration prouve que la vulnérabilité n’est pas un bug isolé de Grok, mais une faille architecturale partagée par l’ensemble des agents IA capables d’orchestrer des actions complexes (navigation web, exécution de code, accès mémoire).

« L’agentic AI (l’IA agentique) est la prochaine grande révolution annoncée par l’industrie. La France y investit massivement via sa Stratégie nationale pour l’IA. Pourtant, ce type d’attaque en révèle la face la plus fragile : un agent qui ne peut pas distinguer une instruction système d’un payload déchiffré exécuté dans son propre environnement est un agent dangereux », analyse un expert en sécurité des LLM.

Selon le rapport OWASP Top 10 pour les applications LLM de 2025, l’injection de prompt (LLM01) reste la menace numéro un, devant la divulgation d’informations sensibles (LLM06). La « Cryptographic Context Injection » en est la variante la plus sophistiquée jamais documentée, car elle neutralise virtuellement toutes les défenses basées sur l’inspection du contenu textuel.

Implications pour les entreprises françaises : RGPD, CNIL et EU AI Act

Pour les DSI, RSSI et DPO français, cette attaque zero-click transforme un risque théorique en menace concrète et quantifiable.

Quelles données sont compromises ?

• Données d’identification : Nom, localisation approximative (déduite de l’adresse IP).
• Données d’abonnement : Type de compte (gratuit, Premium, Premium+).
• Données de contenu : L’intégralité de l’historique des conversations, incluant tous les documents, analyses et données personnelles ou professionnelles qui y ont été partagés.

Ce dernier point est un cauchemar pour la conformité RGPD. Si un avocat, un médecin, un consultant en stratégie ou un responsable RH utilise Grok dans le cadre de son activité, l’intégralité des secrets professionnels de ses clients ou des données sensibles de ses collègues peuvent être exfiltrés sans laisser de trace visible. L’attaque étant zero-click, la victime n’a strictement rien à faire à part une action légitime (demander un résumé de page web).

L’article 33 du RGPD impose une notification à la CNIL sous 72 heures en cas de violation de données présentant un risque pour les droits et libertés des personnes physiques. Une fuite de l’historique complet des conversations professionnelles d’un collaborateur coche très probablement cette case. La CNIL pourrait considérer qu’une entreprise n’a pas rempli son obligation de sécurité des données (article 32 du RGPD) si elle n’a pas mis en place de mesures techniques suffisantes pour prévenir ce type d’exfiltration, notamment une politique d’usage stricte des IA génératives.

Le silence de xAI : un précédent dangereux

Signalée à xAI via la plateforme HackerOne le 3 juin 2026, la vulnérabilité n’a reçu aucun calendrier de correction. Les relances des 4 et 10 août 2026 sont restées sans réponse. À ce jour, aucune CVE n’a été assignée, aucun patch n’a été déployé, et aucune exploitation active dans la nature n’a été confirmée. Cette absence de communication laisse les utilisateurs professionnels de Grok dans une situation d’incertitude préoccupante. Elle interroge également sur la maturité des processus de Responsible Disclosure chez les fournisseurs de LLM.

« Le silence de xAI est inquiétant. En cybersécurité, le temps entre la découverte d’une vulnérabilité et l’apparition d’une exploitation dans la nature est généralement suffisant pour que les équipes de sécurité puissent se préparer. Mais sans correctif ni communication, ce temps devient une zone de risque mort pour les entreprises utilisatrices », commente un consultant en cybersécurité basé à Paris.

Mesures de protection et bonnes pratiques pour contrer l’injection de prompt avancée

Face à cette nouvelle classe d’attaque, les équipes de sécurité françaises doivent dépasser le simple filtrage d’entrée et adopter une approche holistique de la sécurité des agents IA. L’ANSSI, dans ses guides récents sur la sécurisation de l’IA générative, insiste sur plusieurs principes clés.

Tableau comparatif : Injection classique vs Cryptographic Context Injection

Liste des actions à mener pour les RSSI

1. Cartographier les usages des LLM : Identifier précisément quels assistants (Grok, ChatGPT, Gemini, Copilot) sont utilisés et dans quels buts métiers. Un DSI ne peut protéger ce qu’il ne connaît pas.

2. Désactiver les fonctionnalités agentiques superflues : La navigation web et l’exécution de code sont les deux jambes de l’attaque. Si un cas d’usage ne nécessite pas ces deux capacités simultanément, il est impératif de les désactiver pour cet agent. Par exemple, un agent de résumé de documents internes n’a pas besoin d’accéder au web en temps réel.

3. Implémenter le cloisonnement des outils (Tool Air Gap) : Un agent ne devrait jamais pouvoir exécuter du code externe et naviguer sur le web dans la même boucle d’action sans une validation humaine explicite. Cette rupture de chaîne est la défense la plus efficace contre l’exfiltration.

4. Mettre en place une validation des URLs sortantes : Les requêtes HTTP générées par l’IA doivent être inspectées par un proxy. Les navigations vers des domaines inconnus, ou dont le nom de domaine ressemble à une tentative d’exfiltration, doivent être bloquées.

5. Former les utilisateurs à la « Cyber-Hygiène de l’IA » : Les collaborateurs doivent comprendre que les LLM sont des agents actifs. Le partage de données confidentielles dans une conversation Grok expose l’entreprise à un risque de fuite, même sans attaque directe. Avec une attaque zero-click comme celle-ci, le risque de fuite passive devient un risque de fuite active.

6. Auditer les chaînes fonctionnelles (Web → Code → Contexte → Réseau) : Utiliser les outils de votre SOC (SIEM, EDR) pour tracer les enchaînements d’actions provenant de processus LLM. Toute séquence inexpliquée de fetch web, exécution python, accès mémoire et requête HTTP sortante doit être immédiatement investiguée.

Vers une sécurité repensée : le Data Provenance

L’attaque « Cryptographic Context Injection » met en lumière le besoin urgent d’un système de Data Provenance (provenance des données) pour les LLM. Actuellement, une donnée perd son étiquette de source dès qu’elle est traitée par un outil. Les chercheurs d’Adversa AI proposent que les données soient systématiquement marquées par leur source (« Web », « Base de données », « Prompt Utilisateur », « Résultat de Code Interne »). L’agent IA devrait appliquer des niveaux de confiance différents en fonction de cette provenance. Une instruction provenant de la catégorie « Système » ou « Résultat d’outil de confiance » ne devrait jamais pouvoir être dérivée d’un contenu web, même après un déchiffrement ou un calcul.

« Nous avons besoin d’une informatique de la confiance pour les agents IA. Le modèle de sécurité actuel, où tout ce qui est généré par le LLM est considéré comme fiable par défaut, est obsolète face à des attaques comme celle-ci. »

Conclusion : la sécurité des LLM agentiques, un chantier prioritaire pour 2026

L’attaque par injection de prompt chiffré zero-click contre Grok, connue sous le nom de « Cryptographic Context Injection », n’est pas un simple incident de cybersécurité. C’est un signal d’alarme pour toute la filière de l’IA agentique. En exploitant le sandbox Python de l’assistant pour déchiffrer un payload invisible, les attaquants ont démontré qu’il est possible de contourner toutes les défenses textuelles et d’accéder aux données les plus sensibles sans laisser de trace visible.

Pour les entreprises françaises, le message est clair. L’utilisation des LLM publics dans un contexte professionnel expose à des risques de fuite de données massives, potentiellement non couverts par les assurances cyber actuelles. En l’absence de correctif de la part de xAI, la responsabilité de la protection des données incombe entièrement aux utilisateurs professionnels.

La prochaine action concrète pour un RSSI ou un DPO français est de réaliser un audit flash de l’utilisation des agents IA dans son organisation, de réviser la PSSI pour y intégrer les risques d’injection de prompt, et de contacter les fournisseurs d’IA utilisés pour connaître leur position sur les attaques zero-click et leur feuille de route de correctifs. La confiance zero-trust doit désormais s’appliquer aux agents conversationnels, sous peine de voir les secrets les mieux gardés de l’entreprise s’envoler par une simple URL malveillante.