Google refuse de corriger une vulnérabilité critique de « contrebande ASCII » dans son IA Gemini, exposant ainsi les utilisateurs à des attaques cachées. Les chercheurs en sécurité de FireTail ont découvert que les attaquants peuvent utiliser des caractères Unicode invisibles pour intégrer des commandes malveillantes dans du texte.
Pendant que les utilisateurs voient des messages inoffensifs, Gemini exécute les instructions cachées. Cette faille est particulièrement dangereuse dans Google Workspace, où elle permet une usurpation d’identité automatisée dans les invitations et les e-mails de Calendrier.
Bien que des concurrents comme OpenAI et Microsoft aient corrigé des problèmes similaires, Google a rejeté le rapport. L’entreprise l’a classé comme ingénierie sociale et non comme bug de sécurité. Cette décision oblige les entreprises à se défendre contre une menace connue et non atténuée.
Fantômes dans la machine : comment fonctionne la contrebande ASCII
L’attaque, une technique connue sous le nom de contrebande ASCII, trouve son origine dans l’abus intelligent du standard Unicode. Elle exploite une disparité fondamentale entre ce qu’un utilisateur voit sur son écran et les données brutes traitées par un modèle d’IA.
La méthode utilise un ensemble spécial de caractères invisibles du bloc Tags Unicode pour intégrer des instructions cachées dans une chaîne de texte apparemment inoffensive, créant ainsi un vecteur puissant d’injection rapide et d’empoisonnement des données.
Ces caractères spéciaux ne sont généralement pas rendus dans les interfaces utilisateur. Selon la Norme technique Unicode, une implémentation totalement ignorante des balises affichera toute séquence de caractères de balise comme invisible. Cela crée le camouflage parfait pour un attaquant.
Alors qu’un utilisateur humain ne voit que le texte innocent et visible, le flux de données brutes sous-jacent contient une charge utile malveillante cachée à l’intérieur de ces caractères non imprimables.
Les grands modèles de langage (LLM), cependant, n’ont aucune difficulté à interpréter ces commandes cachées. Contrairement à l’interface utilisateur, le préprocesseur d’entrée d’un LLM est conçu pour ingérer des chaînes brutes, y compris chaque caractère, afin de prendre en charge les normes internationales.
Étant donné que ces balises Unicode sont présentes dans leurs vastes données d’entraînement, des modèles comme Gemini peuvent les lire et agir sur elles comme n’importe quel autre texte. Cette technique permet à un attaquant d’ajouter du texte ASCII arbitraire à un emoji ou à d’autres caractères, faisant ainsi passer une invite secrète à tout examinateur humain.
Le résultat est une faille logique critique dans l’application. Le LLM ingère les entrées brutes non fiables et exécute les commandes cachées, tandis que l’utilisateur humain, ne voyant que la version nettoyée dans l’interface utilisateur, reste complètement inconscient de la manipulation.
Cet écart entre la perception humaine et le traitement automatique est au cœur de la vulnérabilité, transformant une bizarrerie de l’interface utilisateur en un risque de sécurité sérieux, comme les chercheurs l’ont démontré à plusieurs reprises.
De l’usurpation d’identité du calendrier. à l’empoisonnement des données
Les implications pour les systèmes d’IA agentique sont graves. Viktor Markopoulos, chercheur chez FireTail, a démontré comment un attaquant pouvait envoyer une invitation à Google Agenda avec une charge utile cachée. Cette charge utile pourrait écraser les informations de l’organisateur, usurper une identité ou insérer un lien malveillant.
Google Gemini, agissant comme un assistant personnel, traite ces données empoisonnées sans aucune interaction de l’utilisateur au-delà de la réception de l’invitation. L’attaque contourne la barrière de sécurité typique « Accepter/Refuser », transformant l’IA en un complice involontaire.
La menace s’étend à tout système dans lequel un LLM résume ou regroupe le texte fourni par l’utilisateur. Par exemple, une évaluation de produit pourrait contenir une commande cachée demandant à l’IA d’inclure un lien vers un site Web frauduleux dans son résumé, empoisonnant ainsi le contenu pour tous les utilisateurs.
Le risque est amplifié pour les utilisateurs qui connectent les LLM à leur boîte de réception de courrier électronique. Comme l’explique Markopoulos,”pour les utilisateurs avec un LLM connecté à leur boîte de réception, un simple e-mail avec des commandes cachées peut demander au LLM de rechercher dans la boîte de réception des éléments sensibles ou d’envoyer des coordonnées, transformant ainsi une tentative de phishing standard en un outil d’extraction de données autonome.”
Cela transforme une tentative de phishing standard en une violation de données automatisée bien plus dangereuse.
Une faille non corrigée : celle de Google. Position face à l’industrie
L’enquête de FireTail a révélé une nette divergence dans l’état de préparation de l’industrie. Alors que Google Gemini, Grok de xAI et DeepSeek se sont tous révélés vulnérables, d’autres acteurs majeurs ne l’étaient pas. Les modèles d’OpenAI, Microsoft et Anthropic semblent avoir mis en œuvre une désinfection des entrées qui atténue la menace.
Après que Markopoulos ait signalé les résultats à Google le 18 septembre, la société a rejeté le problème. Il a fait valoir que l’attaque repose sur l’ingénierie sociale, une position qui a suscité des critiques pour avoir minimisé l’exploit technique en son cœur.
Cette position contraste fortement avec celle d’autres géants de la technologie. Amazon, par exemple, a publié des conseils de sécurité détaillés sur la défense contre la contrebande de caractères Unicode, le reconnaissant comme un vecteur de menace légitime.
Le refus de Google d’agir laisse ses entreprises clientes dans une position précaire. En l’absence de correctif, les organisations utilisant Gemini dans Google Workspace sont désormais sciemment exposées à une méthode sophistiquée d’empoisonnement des données et d’usurpation d’identité.
