Une simple notification de messagerie peut-elle suffire à détourner votre assistant vocal ? C’est la question soulevée par une récente démonstration de sécurité publiée par le laboratoire SafeBreach. Les chercheurs ont mis en lumière une vulnérabilité structurelle affectant Google Gemini sur Android, transformant une fonctionnalité anodine en vecteur d’attaque potentiel.
Cette faille, nommée « Fake Context Alignment », exploite la manière dont l’assistant traite les notifications provenant d’applications tierces comme WhatsApp, Slack ou les SMS. En injectant des instructions cachées dans ces messages, un attaquant peut manipuler le contexte de la conversation sans que l’utilisateur ne s’en rende compte.
Si Google a déployé des correctifs pour atténuer ce risque spécifique, cette recherche rappelle une réalité incontournable : plus nos assistants IA sont intégrés à nos appareils, plus la surface d’attaque s’élargit. Comprendre ce mécanisme est la première étape pour protéger ses données et ses appareils au quotidien.
L’essentiel en 30 secondes
- Vecteur d’attaque : Notifications d’applications tierces (WhatsApp, Slack, SMS) lues par l’assistant.
- Technique : « Fake Context Alignment », injection de prompts indirects cachés dans le texte ou des liens.
- Impact démontré : Contrôle d’appareils connectés, messages trompeurs semblant venir de contacts de confiance, empoisonnement de la mémoire.
- Statut : Selon SafeBreach, Google a déployé des mises à jour de ses classifieurs de contenu afin d’atténuer ces vecteurs d’attaque après divulgation responsable.
- Risque actuel : Faible pour l’utilisateur moyen ayant un appareil à jour, mais le risque structurel persiste pour les IA agentiques.
Le mécanisme de l’attaque : quand une notification devient une commande
La faille repose sur une technique d’injection de prompt indirecte (IPI). Lorsqu’un utilisateur demande à Gemini de lire ou de résumer ses notifications, l’assistant traite le contenu de ces messages comme du contexte utile. Le problème survient lorsque ce contenu contient des instructions dissimulées.
Les chercheurs de SafeBreach ont démontré que ces instructions peuvent être rendues invisibles pour l’utilisateur tout en restant lisibles pour l’IA. Par exemple, en insérant du texte dans une langue étrangère ou en le masquant dans un lien hypertexte muet. L’assistant vocal lit une phrase anodine, mais le système backend voit une commande différente.
Cette divergence entre ce que l’utilisateur entend et ce que le système traite permet de contourner les garde-fous de sécurité. L’utilisateur répond naturellement « oui » à une question inoffensive, validant ainsi, à son insu, l’exécution d’une action sensible en arrière-plan.
Les scénarios démontrés par les chercheurs
Dans le cadre de cette démonstration de recherche, plusieurs scénarios d’exploitation ont été validés, illustrant la diversité des risques liés à cette surface d’attaque infinie que représentent les notifications.
Le contrôle d’appareils connectés via Google Home a été l’un des exemples les plus frappants, permettant théoriquement d’ouvrir des fenêtres motorisées ou de modifier des réglages domestiques. De même, la capacité à lancer des flux vidéo ou audio à distance pose un risque évident pour la vie privée.
Un autre scénario concerne l’empoisonnement de la mémoire à long terme de l’assistant. Une fausse information injectée via une notification sur un téléphone peut se propager à l’ensemble du compte Google Workspace de l’utilisateur, affectant ses interactions futures sur tous ses appareils.
⚠️ Gestes de protection immédiats
Bien que Google ait renforcé ses classificateurs de contenu pour bloquer ces vecteurs, il est prudent d’adopter des réflexes de sécurité simples :
Désactivez la lecture automatique : Limitez la capacité de l’assistant à lire le contenu des notifications sensibles sans votre validation explicite.
Vérifiez les permissions : Restreignez l’accès de l’assistant aux applications de messagerie aux seuls cas d’usage nécessaires.
Méfiez-vous des liens : Ne cliquez jamais sur un lien présent dans une notification si l’assistant vous y invite de manière inattendue, même si le message semble provenir d’un contact connu.
Pourquoi cette faille dépasse le simple bug
Cette recherche ne met pas en évidence une erreur de code classique, mais une faiblesse structurelle inhérente au fonctionnement des modèles de langage. Tant qu’un assistant IA traite à la fois les commandes de l’utilisateur et des données externes non fiables dans le même contexte, le risque de manipulation persiste.
Ce type de dérive illustre un problème déjà documenté, similaire à celui observé avec la manipulation des chatbots de support par les hackers.
La course à l’intégration des IA dans nos systèmes d’exploitation impose aux éditeurs de repenser fondamentalement la gestion de la confiance et des permissions croisées entre les applications. Pour en savoir plus sur les enjeux de régulation, consultez notre analyse sur la CNIL en 2026 et les sanctions à venir.
🔴 Risques des assistants non sécurisés
- Interprétation de commandes cachées
- Exécution d’actions à l’insu de l’utilisateur
- Propagation de fausses informations en mémoire
- Surface d’attaque infinie via les notifications
🟢 Bonnes pratiques de sécurité
- Lecture des notifications désactivée ou restreinte
- Vérification systématique des actions sensibles
- Mise à jour régulière du système et de l’application
- Mécanismes de confirmation explicite activés
Questions fréquentes
Cette faille est-elle activement exploitée par des hackers ? ▼
Non, il s’agit d’une démonstration de recherche réalisée par le laboratoire SafeBreach. À ce jour, aucun cas d’exploitation réelle de cette technique spécifique n’a été signalé dans la nature.
Cette faille concerne-t-elle tous les utilisateurs de Gemini ? ▼
Non. La démonstration publiée par SafeBreach cible surtout Gemini sur Android, dans un scénario où l’assistant traite des notifications provenant d’applications tierces. Cela ne signifie pas que tous les usages de Gemini sont exposés de la même manière. Le risque dépend des permissions accordées, des fonctionnalités activées et des protections déployées côté serveur.
Sources : SafeBreach Labs (recherche originale) et SecurityWeek pour l’analyse des impacts.







