Des chercheurs en sécurité alertent sur une nouvelle façon de détourner le comportement des assistants conversationnels via des pages web. Leur technique, baptisée infection de contexte cryptographique, viserait à amener un chatbot à déchiffrer des instructions cachées, puis à exploiter ses propres capacités d’exécution et de navigation pour extraire des informations privées et les transmettre à un serveur contrôlé par l’attaquant.
Dans le scénario décrit, l’attaque se déclenche lorsqu’un utilisateur demande à l’assistant de résumer une page web « normale ». Le contenu malveillant ne se présente pas comme un texte lisible : il arrive sous forme de données chiffrées, ce qui complique sa détection par des filtres basés sur l’inspection du texte.
Le principe de l’infection de contexte cryptographique
Selon la divulgation, le point central de la méthode est que les instructions de l’attaquant sont transportées comme un chiffre plutôt que comme une requête directement visible. La page contient notamment un objet JSON chiffré, des éléments nécessaires au déchiffrement, ainsi que des consignes. Le chatbot, en traitant ces données, exécuterait alors du code Python au sein de son environnement d’exécution.
Le résultat : une fois le déchiffrement effectué, les consignes ne sont plus « un contenu web à inspecter », mais l’output d’un morceau de code exécuté par le modèle. Autrement dit, les contrôles qui ne réalisent pas les opérations de déchiffrement au moment de l’analyse peuvent laisser passer l’instruction.
Pourquoi le déchiffrement gêne la détection
La divulgation explique que la récupération du texte en clair implique des calculs cryptographiques précis, dont PBKDF2 et AES-256-GCM. Dans cette approche, un classifieur de contenu, tel qu’il est typiquement conçu pour analyser rapidement des entrées, ne réalise pas ces étapes de décryptage « à l’avance ». Le jet de contrôle se fait donc sur ce qui est visible (du chiffré), pas sur ce qui devient vrai après exécution (des instructions en clair).
Ce que le chatbot pourrait exposer
Dans la démonstration ciblant Grok, l’équipe indique que l’attaquant chercherait à faire remonter au serveur contrôlé des informations comme le nom de l’utilisateur, sa localisation approximative, son niveau d’abonnement ainsi que des prompts issus de la conversation en cours.
Le rapport précise que le transfert pouvait se produire sans étape de confirmation et sans avertissement clairement visible pour l’utilisateur, du moins dans le cadre du proof of concept présenté.
Des instructions qui déclenchent une navigation
Après déchiffrement, le mécanisme décrit pousserait l’agent à résoudre le contexte de session et à l’insérer dans un lien que l’agent va ensuite ouvrir. Les données transportées passeraient alors dans les paramètres de requête de cette URL.
Le rapport mentionne aussi une étape où le modèle construirait une sorte de « clé de déchiffrement » qui ne correspond pas au matériel cryptographique lui-même, mais plutôt à une chaîne modèle (template) alimentée par des éléments tels que le nom, la localisation, le niveau et l’historique de discussion. Cette construction permettrait de concaténer le contexte dans la mécanique de déchiffrement et, au final, dans la requête de navigation.
Quelles conditions d’attaque sont rapportées
La divulgation n’avance pas un taux de réussite universel, mais donne des indications de reproduction. D’après les informations fournies, l’attaque a été testée sur la conversation web de grok.com, avec une configuration identifiée comme Grok 4.5 Fast. La reproduction aurait eu lieu à une date précise.
Le même document indique également que l’équipe aurait tenté la technique à plusieurs reprises depuis le mois précédent, avec un taux de réussite d’environ 40% pour les essais effectués. Les échecs seraient dus, dans leurs observations, à des difficultés de déchiffrement rencontrées par le modèle plutôt qu’à un blocage explicite sur une requête ou une réponse.
Absence de correctif et périmètre des impacts
Au moment du rapport, il est indiqué qu’aucun correctif n’était disponible, qu’aucun identifiant de type CVE n’avait été publié et qu’aucune solution de contournement destinée aux utilisateurs n’était rapportée. Le document précise aussi que l’écriture ne fait état d’aucune exploitation « observée dans la nature ».
Concernant le périmètre exact, le rapport affirme que, dans le scénario testé, les prompts exposés seraient limités à la conversation en cours et à ce qui se trouvait déjà dans le contexte du modèle. L’équipe souligne toutefois que la portée de l’agent pourrait s’étendre à tout ce qu’il « détient en contexte » ou qu’il parvient à récupérer via ses outils, sans que la capacité d’accès à d’autres chats, à la mémoire ou à d’autres contenus soit testée.
Le rôle d’un « harness » autour de l’agent
Un message important du rapport consiste à dire que l’on n’est pas obligé de chercher uniquement une solution « au niveau du modèle ». Selon les auteurs, les garde-fous pertinents se trouvent aussi autour de l’agent : comment il s’identifie, ce à quoi il peut accéder, ce qu’il peut écrire, et quelles actions sont rejouables après coup.
En pratique, l’équipe conseille de mettre en quarantaine le contenu non fiable dans un environnement qui ne donne accès à aucun outil ni à aucune donnée d’identification, et de n’en renvoyer au contexte privilégié que des données structurées.
Elle recommande aussi de contrôler les actions irréversibles et les sorties réseau. L’idée : exiger une validation explicite lorsque de nouvelles destinations réseau sont impliquées, ou lorsque des écritures sortent de l’espace de travail, notamment lorsque les arguments seraient complètement résolus plutôt que conservés sous forme de modèles.
Conseils de défense proposés par les chercheurs
- Quarantaine : exécuter l’analyse de contenu non fiable dans un contexte sans outils et sans identifiants, et ne remonter que des données structurées.
- Contrôle des actions : bloquer ou exiger une confirmation humaine pour les actions réseau et irréversibles, en privilégiant des arguments entièrement résolus.
- Traçabilité par session : conserver des traces d’outils avec les arguments effectivement résolus afin de permettre détection et investigation.
- Détection par séquence : surveiller une chaîne d’événements plutôt qu’un seul bloc chiffré ou une seule requête isolée.
- Provenance du contexte : imposer la séparation et la traçabilité de la provenance des données de contexte, et exiger des fournisseurs la question de la séparation entre sorties d’outils et canal d’instructions.
Autres démonstrations citées : Gemini et « payload » chiffré
Le rapport inclut aussi une démonstration visant Gemini en mode « Deep Thinking ». L’idée décrite serait proche : une seule requête forcerait le modèle à déchiffrer une charge utile, dont le contenu pourrait ensuite provoquer une réponse reflétant des éléments d’instructions système ou une altération de politiques.
Le document précise que cette démonstration aurait abouti à du contenu restreint et à la reproduction d’instructions identifiées comme liées à un système de type Gemini (par exemple sur une version « Flash » et un niveau d’abonnement payant). À la différence de Grok, le rapport indique que la notification à l’éditeur n’aurait pas été réalisée, car les jailbreaks seraient hors périmètre du programme de divulgation de l’équipe.
Contexte plus large : attaques et reproductibilités dans les modèles
Au-delà de cette publication, le rapport évoque aussi d’autres travaux de recherche qui, de manière complémentaire, abordent l’impact de blocs chiffrés et d’« instructions invisibles » au sein de chaînes d’exécution. L’objectif commun : montrer que la sécurité peut être contournée non seulement par le texte, mais aussi par la façon dont les entrées sont traitées, déchiffrées et réinjectées dans le contexte actionnable.
Le document mentionne également des observations antérieures de la même famille de problèmes autour de Grok, dont des démonstrations visant l’exfiltration de données via l’application mobile. Dans ce type d’échanges, la question revient souvent : l’existence d’une « clôture » de la vulnérabilité et la sévérité réelle de l’impact observé.
Ce que les équipes produit peuvent retenir
Si l’infection de contexte cryptographique se confirme comme menace réaliste dans d’autres environnements, l’enjeu se situe moins dans la robustesse « pure » du modèle, et davantage dans l’architecture autour des agents. Dès lors, la priorité devient de réduire le risque qu’un contenu web non fiable influence des outils privilégiés, notamment via des chaînes de déchiffrement.
Concrètement, la stratégie défensive la plus récurrente consiste à empêcher la transformation de données externes chiffrées en instructions exécutables dans un canal qui peut déclencher des actions réseau ou révélatrices. En parallèle, la mise en place de traces et de contrôles de provenance permettrait de détecter ces attaques lorsque des séquences suspectes apparaissent.
En attendant d’éventuels correctifs spécifiques, le message central est clair : ne pas supposer que le chiffré est neutre. Dans ce rapport, c’est précisément la capacité de déchiffrement et la réinjection de contexte qui ouvrent la voie à l’exfiltration.
Source: https://thehackernews.com/2026/08/new-cryptographic-context-injection.html
