Les bots d'e-mails IA volent des mots de passe via du CSS caché, contournant Outlook et Gmail

Lors de la conférence Black Hat USA 2026, des chercheurs ont démontré que les feuilles de style en cascade (CSS) peuvent être transformées en armes pour forcer les agents d'e-mails pilotés par l'IA à lire du contenu invisible pour les utilisateurs humains. La technique a contourné Outlook, Gmail, Yahoo et Proton, permettant aux agents d'exfiltrer des mots de passe, des jetons d'authentification et des adresses IP.

Pourquoi le CSS est crucial pour la sécurité des e-mails

Depuis des années, les fournisseurs de messagerie Web se défendent contre le HTML malveillant en supprimant les scripts, en isolant les iframes dans des bacs à sable (sandboxing) et en limitant les actions possibles d'un message. Ces mesures bloquent les attaques classiques reposant sur JavaScript ou des objets intégrés. Le CSS, en revanche, a toujours été considéré comme un code de présentation inoffensif. Ses sélecteurs avancés — sélecteurs d'attributs, requêtes de conteneur (container queries) et autres — permettent à une page de réagir à la structure du DOM sans aucun script.

Les démonstrations de Black Hat ont prouvé que ces sélecteurs « inoffensifs » peuvent devenir un canal auxiliaire (side-channel) pour la fuite de données. En concevant des règles de style qui ne s'appliquent que lorsque certains éléments cachés existent, les attaquants rendent le texte invisible pour l'utilisateur, tout en le laissant présent dans la page rendue que l'agent d'IA analyse.

Comment fonctionnent les attaques

Une preuve de concept a consisté à envoyer un e-mail d'apparence ordinaire au destinataire. À l'intérieur se cachaient des règles CSS qui changeaient la couleur d'un texte spécifique pour qu'elle corresponde à celle de l'arrière-plan, le rendant ainsi invisible. Un humain ne voit jamais le texte, mais un agent d'IA qui extrait le DOM ou l'arbre d'accessibilité n'applique pas le filtre visuel. Lorsque l'agent a traité l'e-mail, il a lu le texte dissimulé et l'a transmis dans un fragment d'URL — une partie d'une adresse web que les navigateurs ignorent normalement lors du chargement d'une page.

Une autre variante utilisait l'injection de prompt indirecte. L'e-mail contenait un jeton Slack caché. Le CSS rendait le jeton invisible pour l'utilisateur tout en le maintenant dans le balisage. L'agent d'IA, entraîné à suivre les instructions intégrées dans l'e-mail, a interprété le jeton comme une commande et l'a renvoyé vers le serveur de l'attaquant.

Les deux attaques ont réussi contre le même ensemble de fournisseurs populaires, démontrant que la vulnérabilité provient de la manière fondamentale dont le CSS est rendu, et non de l'implémentation d'une plateforme unique.

Agents d'IA contre lecteurs humains

Les humains ignorent instinctivement le texte qu'ils ne peuvent pas voir ; nous faisons confiance à la mise en page visuelle pour nous indiquer ce qui est important. Les agents d'IA, en revanche, opèrent sur le DOM brut ou sur un arbre d'accessibilité qui enregistre chaque élément, quel que soit son état visuel. Lorsqu'une IA lit une page, elle n'applique pas la règle du « si je ne peux pas le voir, je l'ignore ». Ce décalage crée un angle mort : les pipelines de nettoyage conçus pour la consommation humaine ne garantissent plus la sécurité pour les lecteurs automatisés.

Le problème n'est pas une nouvelle faille de l'IA. C'est une ancienne faille du Web — la capacité du CSS à affecter la mise en page sans code — qui rencontre un nouveau type de consommateur. Tout service qui confie le contenu d'un e-mail à un assistant, un résumeur ou un classificateur alimenté par l'IA s'expose désormais au risque que l'assistant agisse sur des données qu'un humain ne verra jamais.

Qui est responsable de la défense ?

Les attaques soulèvent une question de responsabilité. Les fournisseurs de messagerie Web nettoient déjà le HTML pour protéger les utilisateurs humains ; les navigateurs appliquent déjà les mêmes règles de rendu. Pourtant, aucune de ces couches ne prend en compte l'IA en aval qui analysera le même balisage. Les services de messagerie devraient-ils ajouter une désinfection CSS plus approfondie ? Les navigateurs devraient-ils exposer un indicateur (flag) marquant les éléments comme « invisibles pour les scripts » ? Ou les fournisseurs d'IA doivent-ils construire des filtres qui rejettent les nœuds cachés avant le traitement ?

On conseille aux équipes de sécurité qui développent des outils d'e-mail pilotés par l'IA d'auditer l'intégralité du pipeline de rendu, et pas seulement le HTML qui arrive dans la boîte de réception. Cela signifie vérifier le DOM après l'application du CSS, inspecter l'arbre d'accessibilité et supprimer ou signaler explicitement tout contenu qui n'est pas visible à l'œil humain.

À surveiller ensuite

• Tests des fournisseurs – Les fournisseurs d'IA devraient intégrer des vecteurs d'attaque CSS réels dans leurs suites de tests. Le Web dispose de trente ans de recherche sur les vulnérabilités ; les agents d'IA n'en ont que quelques-uns.

Si un assistant d'IA peut être piégé pour divulguer des identifiants simplement en cachant du texte avec du CSS, le modèle de sécurité qui protège les boîtes de réception actuelles n'est plus suffisant. Les développeurs, les fournisseurs et les régulateurs doivent traiter la page rendue — et pas seulement le HTML brut — comme la limite de sécurité pour tout consommateur automatisé. Le problème du texte caché nous rappelle qu'une technologie autrefois reléguée au « simple stylisme » peut devenir un vecteur de vol de données. La prochaine vague de défenses devra reconnaître le CSS comme une surface d'attaque potentielle, et non plus seulement comme une aide visuelle.