Un éternel recommencement ?
Les chercheurs de l’entreprise de cybersécurité Radware ont mis en garde, le 8 janvier 2026, contre une nouvelle attaque par injection indirecte visant ChatGPT. Cette offensive détourne une mécanique que l’on pensait réglée depuis quelques mois et cible spécifiquement l’outil Deep Research du chatbot.
Microsoft le concédait une nouvelle fois en juillet 2025 : l’injection de prompt est « un risque inhérent » au LLM. Il n’empêche que les acteurs de la cybersécurité restent déterminés à explorer toutes les variantes possibles de cette faille, en particulier celles pouvant conduire à des fuites massives de données sensibles.
Cette histoire débute à l’automne 2025, lorsque l’entreprise de cybersécurité Radware révèle ShadowLeak, une attaque par injection indirecte qui exploite l’agent Deep Research de ChatGPT.
Ce mode de recherche, disponible dans les versions récentes du chatbot, permet à l’IA de parcourir le web mais aussi des connecteurs comme Gmail ou Google Drive pour produire un rapport détaillé à partir des données de l’utilisateur.
Pratique donc, mais à travers ShadowLeak, les chercheurs ont su déceler un mécanisme particulièrement fourbe reposant sur l’incapacité des modèles de langage à distinguer parfaitement les instructions explicites de l’utilisateur, des instructions cachées dans des contenus externes.
Les LLM sont-ils voués à être vulnérables aux injections de prompt ? // Source : Montage Numerama ShadowLeak, la première alerte
Concrètement, ShadowLeak consiste pour l’attaquant à envoyer à sa cible un mail en apparence anodin, par exemple sur un sujet RH, mais contenant des instructions malveillantes dissimulées en très petite police ou en blanc sur fond blanc.
Ces instructions indiquent à l’agent Deep Research quoi faire : repérer un autre mail RH légitime contenant des informations personnelles (nom, adresse, etc.), encoder ces données en Base64, puis les ajouter à une URL présentée comme un service interne de l’entreprise mais en réalité contrôlée par l’assaillant, par exemple « services-rh-club.fr ».
Prenons un cas concret pour y voir plus clair : si un candidat nommé Louis est en cours de recrutement et qu’un recruteur demande à Deep Research de consulter ses mails, l’agent lira les instructions cachées dans le mail envoyé par l’attaquant, récupérera les informations sur Louis dans un autre message, les encodera en Base64 (par exemple « Louis » devenant « TG91aXM= »), puis les ajoutera à l’URL de l’attaquant.
Côté serveur, le pirate pourra ainsi voir une requête vers « services-rh-club.fr/TG91aXM= », qu’il lui suffit de décoder pour retrouver « Louis », la même méthode pouvant servir à exfiltrer des données bien plus sensibles, comme une adresse postale, des informations bancaires ou des mots de passe partagés en clair.
Le succès de l’attaque repose sur le soin apporté au texte malveillant et à l’ingénierie sociale visant à faire baisser la garde du chatbot : le message évoque une fausse « autorisation complète », maquille l’URL d’exfiltration en service interne, présente l’encodage Base64 comme une mesure de sécurité, et menace de conséquences négatives si la dernière étape n’est pas réalisée.
Après plusieurs essais infructueux, les chercheurs sont parvenus à une stratégie gagnante : en encodant les données avant l’appel réseau et en introduisant des consignes de persistance (« réessaie plusieurs fois »), ils ont atteint un taux de réussite de 100%, l’agent encodant systématiquement les données personnelles et les envoyant dans l’URL comme demandé.
Réaction d’OpenAI et ZombieAgent
Face aux découvertes des chercheurs, OpenAI a d’abord appliqué un correctif empêchant l’agent de modifier dynamiquement les URL utilisées par ses outils, en particulier d’y ajouter des paramètres contenant des informations potentiellement sensibles, afin de bloquer la construction d’URL « sur mesure » comme dans ShadowLeak.
Mais les équipes de Radware viennent de dévoiler au site britannique The Register une nouvelle technique pour tromper ChatGPT, baptisée ZombieAgent, qui montre que cette défense ne traite qu’une partie du problème.
Au lieu de demander à l’agent de fabriquer une URL unique contenant le secret, la nouvelle attaque s’appuie sur un ensemble d’URL statiques préparées à l’avance, chacune se terminant par un caractère différent.
Concrètement, l’attaquant dispose d’un « alphabet » d’URLs : une pour « a », une pour « b », une pour « c », et ainsi de suite. Des instructions cachées demandent à l’agent de parcourir le secret caractère par caractère et, pour chaque lettre, d’ouvrir l’URL correspondante.
L’agent ne modifie jamais de lien, il se contente de sélectionner parmi une liste d’URLs déjà présentes dans le contenu, ce que la nouvelle politique d’OpenAI n’interdit pas.
Côté attaquant, la reconstitution est triviale : en observant simplement l’ordre d’arrivée des requêtes sur son serveur (dans notre exemple « /l », puis « /o », puis « /i », puis « /s ») il peut reconstruire le mot de passe ou la donnée sensible fuitée caractère par caractère.
Pour l’heure, OpenAI n’a pas encore réagi à cette nouvelle manière de compromettre son agent.
merci à Numerama
