Les attaques CSS contre le webmail révèlent un angle mort dans les défenses e-mail basées sur l’IA
Google News a mis en lumière une attaque CSS contre le webmail observée dans plus d’un million de messages de phishing depuis avril 2026. Cette campagne révèle un conflit fondamental dans la sécurité des e-mails fondée sur l’IA. Les humains et les machines peuvent recevoir le même message, mais en lire des contenus radicalement différents.
La technique signalée, appelée text salting, utilise les feuilles de style en cascade pour dissimuler du texte de remplissage dans un e-mail HTML. Ce contenu caché modifie l’interprétation du message par les systèmes automatisés sans changer ce que voit le destinataire.
Des chercheurs de Barracuda ont identifié cette technique dans des campagnes de phishing sur le thème du commerce de détail, promettant des récompenses, des cartes-cadeaux, des points de fidélité ou des échanges urgents. Les attaquants ont utilisé du texte caché pour diluer les formulations suspectes et faire paraître les e-mails malveillants plus sûrs aux filtres automatisés.
Il ne s’agit pas simplement d’une nouvelle technique pour contourner les filtres antispam. Le même écart de visibilité peut fonctionner dans l’autre sens. Des instructions cachées peuvent cibler un assistant IA qui résume les e-mails, rédige des réponses, recherche dans une boîte aux lettres ou invoque des outils connectés.
C’est là que se situe le principal compromis de sécurité. Les outils d’e-mail basés sur l’IA deviennent plus utiles à mesure qu’ils lisent davantage de contexte et reçoivent des accès plus étendus. Ces mêmes capacités amplifient les conséquences lorsqu’un contenu d’e-mail non fiable influence le modèle.
Les défenses traditionnelles supposent que le message affiché à une personne est globalement équivalent à celui inspecté par le logiciel. Le CSS brise cette hypothèse en créant, dans un même e-mail, des versions distinctes lisibles par l’humain et par la machine.
La pression immédiate s’exerce sur Google, Microsoft, les fournisseurs de sécurité e-mail et les développeurs qui créent des assistants reposant sur les données des boîtes aux lettres. Ils doivent concilier l’analyse du message brut et son contenu rendu, tout en préservant l’accessibilité et la mise en forme légitime.
Ce que le rapport de Google News révèle sur le text salting
Le changement important n’est pas que les attaquants ont découvert le texte caché. C’est que d’anciennes méthodes d’évasion fonctionnent désormais contre les jugements fondés sur l’IA.
Le text salting ajoute à un message malveillant des mots inoffensifs ou sans rapport avec son contexte. Les logiciels de sécurité analysent ces mots, mais le CSS empêche le destinataire de les voir.
Barracuda a indiqué avoir détecté un million d’attaques utilisant ces techniques depuis avril 2026. Les messages faisaient partie d’une campagne sur le thème du commerce de détail, construite autour de récompenses et d’offres d’échange.
Les attaquants ont utilisé plusieurs propriétés CSS ordinaires. clip-path: inset(100%) réduisait à néant la zone visible d’un bloc de texte. Des règles de hauteur et d’interligne nuls éliminaient les espaces vides suspects.
D’autres règles repoussaient le texte au-delà de la limite de l’écran. Un text-indent négatif important le déplaçait de milliers de pixels vers la gauche, tandis que overflow: hidden supprimait toute barre de défilement révélatrice.
Les attaquants réduisaient également les polices à zéro. Aucune de ces propriétés n’est intrinsèquement malveillante. Cette ambiguïté rend une simple liste de blocage peu fiable, car des modèles d’e-mails légitimes peuvent utiliser des techniques de style similaires.
La campagne aurait reposé sur des sites web compromis ou des domaines d’imitation. Certains domaines prenaient en charge une authentification e-mail standard, notamment DomainKeys Identified Mail, ou DKIM, qui vérifie qu’un domaine autorisé a signé un message.
DKIM ne détermine pas si le contenu est honnête. Il valide la gestion et l’intégrité d’un message au niveau du domaine. Un opérateur malveillant qui contrôle un domaine authentifié peut toujours diffuser du phishing.
Cette distinction compte, car les systèmes d’IA combinent souvent de nombreux signaux. L’authentification, le langage naturel, la réputation de l’expéditeur, les liens visibles et la structure du message peuvent tous influencer une classification.
Le text salting manipule le signal linguistique. Il fournit à un classificateur un volume plus important de texte apparemment inoffensif, tout en laissant l’appât de phishing clairement visible pour le destinataire humain.
Un filtre examinant le HTML brut pourrait rencontrer des paragraphes sur des activités commerciales sans rapport, le service client ou des transactions de détail ordinaires. Le destinataire, lui, pourrait ne voir qu’un avis urgent concernant une récompense et un bouton.
Cela crée une version sémantique de l’entrée adversariale. L’attaquant n’exploite pas nécessairement une faille de mémoire logicielle. Il façonne les éléments de preuve utilisés par un système de décision statistique.
L’IA générative réduit également le coût de production de textes de remplissage variés. Les attaquants peuvent créer des passages inoffensifs différents pour chaque message, réduisant l’intérêt de la correspondance textuelle exacte.
Le titre de Google News pointe donc vers une évolution plus large. Le contenu d’un e-mail peut désormais être conçu pour deux publics, avec une histoire pour l’utilisateur et une autre pour la machine.
Pourquoi les filtres e-mail basés sur l’IA font face à un problème de rendu
Un modèle d’IA ne peut pas évaluer un e-mail de manière fiable lorsque son entrée ne correspond pas au message affiché au destinataire.
De nombreux systèmes de sécurité e-mail inspectent le contenu brut des messages, car celui-ci contient des éléments de preuve précieux. Il révèle les URL, les attributs HTML, les métadonnées, les sections encodées et le texte que le rendu peut masquer.
Cette approche était pertinente lorsque le texte caché ciblait principalement le filtrage antispam fondé sur des mots-clés. Les défenseurs pouvaient rechercher des mises en forme suspectes et comparer les mots visibles avec la source sous-jacente.
Les grands modèles de langage compliquent le processus. Ils peuvent déduire le sens à travers de longs passages, mais cette capacité donne aussi davantage d’influence au texte de remplissage caché sur la classification.
Un modèle pourrait voir un message dominé par un langage commercial ordinaire. Sa demande de phishing visible ne pourrait représenter qu’une petite partie de l’entrée totale lisible par la machine.
L’attaque n’exige pas que le modèle suive une commande directe. Elle peut réussir en modifiant suffisamment le sujet, le ton ou l’intention apparents pour obtenir une classification bénigne.
L’analyse du rendu présente ses propres difficultés. Les clients de messagerie diffèrent dans leur prise en charge du HTML et du CSS. Un message peut s’afficher différemment dans Gmail, Outlook, les applications mobiles et des logiciels de webmail spécialisés.
Les fonctions d’accessibilité peuvent également exposer du texte qu’un rendu visuel par défaut cache. Les lecteurs d’écran, les modes à contraste élevé et les affichages simplifiés compliquent toute affirmation sur une présentation unique et définitive.
Les outils de sécurité ont donc besoin de plus qu’une capture d’écran. Ils nécessitent une comparaison structurée entre le contenu brut, la mise en page calculée, la sortie d’accessibilité et les éléments qu’un utilisateur typique peut percevoir.
La question la plus utile n’est pas de savoir si une propriété paraît suspecte de manière isolée. Il s’agit de déterminer si le style crée une différence significative entre l’interprétation de la machine et la perception humaine.
Un paragraphe de taille nulle contenant des centaines de mots sans rapport est un signal plus fort qu’une simple étiquette de mise en forme cachée. Les grands blocs situés hors écran méritent une attention similaire.
Les défenseurs peuvent aussi comparer le sens linguistique des régions visibles et cachées. Un message sur des récompenses de fidélité ne devrait pas contenir des paragraphes dissimulés sur des factures, des voyages ou le support client sans rapport.
Les attaquants peuvent toutefois s’adapter. Ils peuvent générer du texte de remplissage qui reste proche du sujet visible, réduisant l’écart sémantique tout en diluant les formulations malveillantes.
Cela crée une course aux armements entre la génération de contenu et la détection tenant compte de la visibilité. Un filtre doit comprendre non seulement ce que dit le message, mais aussi quelles parties importent à la personne qui le reçoit.
L’apprentissage automatique n’est pas inutile dans ce contexte. Il reste précieux pour détecter les anomalies structurelles, les schémas d’expéditeurs, l’infrastructure des campagnes et les combinaisons inhabituelles de règles de style.
Le problème réside dans une confiance excessive envers l’architecture. Un modèle de langage ne peut pas compenser une chaîne d’entrée qui fusionne des instructions fiables, du contenu non fiable et du matériel invisible sans frontières claires.
Google a décrit une défense en couches contre l’injection indirecte de prompts. Son approche comprend des classificateurs de contenu, un entraînement adversarial, du red teaming et une confirmation avant les actions sensibles.
Ces contrôles illustrent la direction que doivent prendre les défenses e-mail. Aucun verdict rendu par un seul modèle ne devrait décider si un message est sûr, en particulier lorsque le CSS modifie ce que reçoivent différents observateurs.
Le contenu caché peut cibler le filtre ou l’assistant
Le même écart de visibilité créé par le CSS permet deux attaques opposées : cacher du texte inoffensif aux humains et leur cacher des instructions malveillantes.
Le text salting tente de faire paraître un e-mail malveillant bénin à un système de sécurité. L’injection indirecte de prompt tente de faire obéir un assistant IA à des instructions que l’utilisateur n’a jamais fournies sciemment.
OWASP définit l’injection indirecte de prompt comme des instructions malveillantes intégrées à un contenu externe qu’un système d’IA traite ultérieurement. L’e-mail constitue un canal de diffusion naturel, car n’importe qui peut envoyer une entrée dans de nombreuses boîtes aux lettres.
Un attaquant peut masquer des instructions à l’aide de texte blanc, de polices de taille nulle, d’un positionnement hors écran, de caractères encodés ou de structures HTML omises par le moteur de rendu visuel.
La victime peut demander à un assistant de résumer les messages non lus. Un flux de travail autonome peut traiter la boîte de réception sans demande directe. Dans les deux cas, le modèle peut rencontrer des instructions rédigées par l’attaquant.
Une attaque simple peut manipuler un résumé. L’IA pourrait inventer une alerte de sécurité, supprimer un indicateur de phishing ou présenter un message malveillant comme approuvé.
Une attaque plus grave devient possible lorsque l’assistant peut rechercher dans d’autres messages, lire des documents connectés, rédiger des e-mails sortants ou appeler des outils externes.
L’e-mail malveillant agit alors comme une entrée de contrôle. Il peut tenter de détourner l’assistant de la tâche de l’utilisateur vers la récupération de données, leur divulgation ou une action non autorisée.
Microsoft a annoncé une protection contre l’injection dans la boîte de réception dans Defender for Office 365 en juillet 2026. Cette fonctionnalité a été publiée en préversion publique pour les clients éligibles.
Microsoft indique que le système détecte les instructions d’IA malveillantes lors de l’inspection du flux de messagerie. Les messages détectés reçoivent un verdict de phishing à haute confiance et peuvent être isolés avant d’atteindre les utilisateurs ou les assistants connectés.
Cet emplacement est important. Bloquer une attaque avant sa livraison l’empêche d’entrer dans les index de recherche de boîtes aux lettres, les systèmes de récupération, les résumés et le contexte des agents en aval.
Toutefois, la détection à la passerelle ne peut pas résoudre tous les cas. Un attaquant peut placer des instructions malveillantes dans un compte interne compromis, une liste de diffusion autorisée, un fil transféré ou une pièce jointe.
La distinction entre les instructions et les données reste également difficile pour les modèles de langage. Toutes deux arrivent sous forme de langage naturel et peuvent contenir des demandes, des commandes citées ou du texte procédural.
Un e-mail d’un responsable peut légitimement indiquer : « Examinez le fichier joint et envoyez votre réponse. » Une injection malveillante peut employer un langage presque identique tout en s’adressant à l’IA plutôt qu’à l’employé.
L’assistant doit déduire l’autorité, la provenance et l’intention. La seule maîtrise du langage naturel n’offre pas ces propriétés de sécurité.
C’est pourquoi l’attaque contre le filtre et l’attaque contre l’assistant relèvent de la même discussion. Toutes deux exploitent l’ambiguïté entre le contenu affiché, le contenu traité et le contenu autorisé.
Google News a mis en avant une histoire sur les défenses e-mail propulsées par l’IA, mais les implications vont au-delà de la classification du spam. Chaque agent connecté à une boîte aux lettres hérite de ce problème non résolu de frontière des entrées.
EchoLeak a montré ce qui se produit lorsque les e-mails atteignent les outils
Un e-mail caché devient nettement plus dangereux lorsqu’un assistant IA peut récupérer du contexte privé et communiquer au-delà de la boîte aux lettres.
La divulgation d’EchoLeak en 2025 a constitué un avertissement concret. Des chercheurs ont décrit une attaque en plusieurs étapes impliquant Microsoft 365 Copilot et un e-mail soigneusement conçu.
Microsoft identifie EchoLeak comme CVE-2025-32711 et indique que le problème a été corrigé. L’entreprise le décrit comme une technique d’injection inter-invites susceptible d’exposer des données limitées déjà accessibles à une victime.
Selon les recommandations de sécurité de l’IA de Microsoft, un message d’apparence bénigne pouvait empoisonner le contexte traité par Copilot. Cette technique pouvait ensuite provoquer une divulgation involontaire dans certaines conditions.
L’incident était important car il ne reposait pas d’abord sur le vol du mot de passe de l’utilisateur. Il ciblait l’assistant à travers des données que celui-ci était censé lire.
EchoLeak était plus complexe que la campagne de text salting mise en avant par Google News. Il impliquait plusieurs étapes et conditions, tandis que le text salting cherchait principalement à contourner la classification.
Pourtant, les deux cas remettent en cause la même hypothèse. L’e-mail est considéré comme du contenu, alors que certaines parties de ce contenu peuvent agir comme des instructions adverses pour les systèmes d’IA.
Le risque augmente avec la génération augmentée par récupération, ou RAG. Cette conception récupère des informations privées pertinentes et les ajoute au contexte d’un modèle avant de générer une réponse.
Le RAG aide un assistant de messagerie à répondre à des questions sur des projets, des calendriers, des clients et des discussions précédentes. Il place également des informations précieuses à proximité de contenu de message contrôlé par un attaquant.
L’accès aux outils ajoute une couche supplémentaire. Un assistant limité aux résumés peut induire un utilisateur en erreur, mais un agent disposant d’outils de messagerie ou de fichiers peut entraîner des conséquences opérationnelles directes.
Les développeurs s’appuient souvent sur une invite système demandant au modèle d’ignorer les instructions malveillantes. Cette mesure aide, mais elle ne constitue pas une frontière de sécurité stricte.
Un vaste défi de recherche appelé LLMail-Inject a recueilli 208 095 soumissions d’attaque de 839 participants. Les chercheurs ont testé plusieurs défenses, modèles et configurations de récupération dans un environnement réaliste d’agent de messagerie.
Le volume des soumissions est important, car les attaquants adaptatifs ne répètent pas une seule phrase évidente. Ils testent les transformations, le cadrage, l’encodage, le contexte social et les comportements propres aux modèles.
Les défenseurs doivent supposer que tout classificateur ou garde-fou d’invite peut générer des faux négatifs. Les actions sensibles nécessitent des contrôles d’autorisation indépendants qui ne dépendent pas de l’interprétation du modèle.
Un outil de synthèse d’e-mails ne devrait pas obtenir l’autorisation d’envoyer des messages simplement parce qu’il peut les lire. L’accès à la recherche ne devrait pas impliquer l’accès à chaque dossier de boîte mail ou document connecté.
Les appels d’outils doivent suivre le principe du moindre privilège, qui n’accorde à chaque composant que les autorisations nécessaires à sa tâche actuelle. Les actions à fort impact doivent exiger une confirmation explicite de l’utilisateur.
Les équipes de sécurité ont également besoin de journaux indiquant quel message a influencé une sortie ou une action. Sans traçabilité, un intervenant en réponse aux incidents ne peut pas facilement identifier l’entrée empoisonnée.
Les utilisateurs qui gèrent des sources pour des systèmes d’IA font face à un défi connexe. Une capture d’informations claire et une séparation des sources peuvent aider à préserver le contexte, mais les autorisations au niveau de l’application restent essentielles.
La leçon d’EchoLeak n’est pas que tous les assistants de messagerie sont dangereux. C’est que leur sécurité doit suivre leur niveau d’autorité, et non leur apparence conversationnelle.
Le compromis défensif oppose visibilité et utilité
Supprimer chaque élément caché réduirait certaines attaques, mais nuirait aussi aux e-mails légitimes et laisserait intactes des défaillances d’autorisation plus profondes.
Un nettoyeur strict pourrait retirer le CSS, les éléments cachés, les ressources distantes et le HTML complexe avant qu’un système d’IA ne lise un message. Cela réduirait considérablement la surface d’attaque.
Il supprimerait également une structure qui aide les utilisateurs et les modèles à comprendre les e-mails légitimes. Les tableaux, mises en page réactives, citations, signatures, libellés d’accessibilité et formats transactionnels peuvent véhiculer un sens utile.
Certains contenus cachés servent des objectifs opérationnels. Le texte de pré-en-tête peut fournir un bref aperçu dans la boîte de réception, tandis que les conceptions réactives affichent différents éléments sur les écrans de bureau et mobiles.
Les produits de sécurité doivent distinguer ces cas d’un grand bloc dissimulé conçu pour manipuler la classification. La décision ne peut pas reposer sur une seule propriété CSS.
Le rendu de chaque message dans un navigateur contrôlé peut améliorer l’analyse de visibilité. Il augmente aussi les coûts de calcul et introduit un moteur de navigateur dans la chaîne de sécurité.
Une vue rendue peut malgré tout ne pas correspondre à tous les clients. La largeur mobile, le mode sombre, les images bloquées, les paramètres linguistiques et les préférences d’accessibilité peuvent tous modifier le résultat.
La stratégie la plus sûre utilise plusieurs représentations. Un système peut conserver le contenu brut pour l’analyse forensique, calculer une vue normalisée et identifier séparément les régions cachées ou peu visibles.
Le classificateur d’IA devrait recevoir des étiquettes explicites pour ces régions. Le contenu caché ne devrait pas entrer silencieusement dans le même flux de texte indifférencié que le contenu visible.
Un assistant pourrait traiter le texte dissimulé comme des métadonnées non fiables. Il pourrait ne résumer ce contenu caché que lorsque l’utilisateur demande une analyse de sécurité.
Les détecteurs d’injection d’invites fournissent une autre couche. L’implémentation de Microsoft examine les objets, corps des messages, HTML, styles, contenus transférés et éléments encodés avant qu’un assistant ne les traite.
Néanmoins, la détection d’injection d’invites est probabiliste. Des e-mails légitimes peuvent contenir des discussions sur les invites, les tests de sécurité, les commandes d’automatisation ou des messages malveillants cités.
Une équipe de recherche peut recevoir par e-mail de véritables échantillons d’attaque. Un filtre de sécurité pourrait mettre ces messages en quarantaine même lorsque le destinataire les attend.
Les faux positifs créent une pression pour assouplir l’application des règles. Si des e-mails importants disparaissent trop souvent, les administrateurs ajoutent des exceptions que les attaquants peuvent étudier et exploiter.
La confirmation humaine est également imparfaite. Les utilisateurs approuvent régulièrement des demandes lorsqu’une interface les présente comme des étapes normales, en particulier pendant un travail répétitif.
La confirmation doit donc expliquer l’action proposée, sa cible et les données concernées. Une invite vague demandant s’il faut « continuer » offre peu de protection.
La conception la plus robuste sépare le raisonnement du modèle de l’application des politiques. Le modèle peut suggérer une action, tandis qu’un logiciel déterministe vérifie les autorisations, destinations, classifications des données et exigences d’approbation.
Cette approche limite les dommages causés tant par les invites cachées que par les erreurs ordinaires du modèle. Un assistant manipulé ne peut pas dépasser les limites appliquées en dehors de son contexte linguistique.
Le compromis est une moindre commodité. Les utilisateurs peuvent être confrontés à davantage d’invites, à des intégrations plus limitées et à une automatisation plus lente pour les tâches à haut risque.
Cette friction est justifiée lorsqu’un assistant peut envoyer des messages externes, récupérer des documents confidentiels, modifier des dossiers ou lancer des flux de travail financiers. Les résumés à faible risque peuvent conserver des contrôles plus légers.
Les outils d’IA pour e-mails devraient donc utiliser une autorité graduée. Lire un message sélectionné, rechercher dans un dossier, rédiger une réponse et envoyer cette réponse devraient rester des niveaux d’autorisation distincts.
Ce que les équipes de sécurité devraient surveiller ensuite
La prochaine phase se mesurera à la qualité de détection, à la conception des autorisations et aux preuves d’abus dans le monde réel, plutôt qu’à un nouveau benchmark de modèle.
Le premier signal est une disponibilité plus large de l’inspection des e-mails tenant compte de la visibilité. L’aperçu public de Microsoft montre que l’injection d’invites devient une catégorie distincte de sécurité de messagerie.
Les équipes de sécurité devraient surveiller la manière dont les fournisseurs exposent ces détections. Les produits utiles identifieront la région cachée, expliqueront son rôle et préserveront les éléments de preuve nécessaires à l’enquête.
Un verdict générique de phishing ne suffit pas. Les analystes doivent savoir si un message contenait du remplissage CSS caché, une instruction encodée, des directives d’outils suspectes ou un décalage inhabituel entre le contenu visible et le contenu brut.
Le deuxième signal est la façon dont Google, Microsoft et les développeurs tiers limitent les agents connectés aux boîtes mail. Les améliorations de modèles comptent moins que des limites applicables autour de la récupération et de l’utilisation des outils.
Les acheteurs devraient demander si les assistants distinguent les messages externes des instructions internes. Ils devraient également demander si le contenu récupéré conserve l’identité de l’expéditeur, son emplacement et son niveau de confiance.
Les administrateurs ont besoin de contrôles pour des actions précises. Une politique devrait autoriser la synthèse sans autoriser automatiquement l’envoi d’e-mails sortants, l’accès aux fichiers, les modifications de calendrier ou les appels d’API tierces.
Le troisième signal est la preuve vérifiée d’exploitation. Les données de Barracuda sur le text salting montrent un déploiement à grande échelle contre les filtres, mais elles n’établissent pas que chaque message a contourné un produit fondé sur un LLM.
Les fournisseurs devraient publier leur méthodologie et leurs dénominateurs lorsque cela est possible. Les seuls décomptes de détection ne révèlent ni les taux de livraison, ni les classifications réussies, ni l’interaction des victimes, ni les compromissions en aval.
La même prudence s’applique aux démonstrations d’injection d’invites. Une attaque en laboratoire prouve qu’un chemin de sécurité existe, mais les contrôles de production peuvent modifier sa fiabilité pratique.
À l’inverse, l’absence d’incidents publics ne prouve pas la sécurité. La manipulation d’agents d’IA peut ressembler à une activité utilisateur ordinaire, ce qui rend les incidents difficiles à identifier sans journaux détaillés.
Les organisations n’ont pas besoin d’attendre des mesures parfaites. Elles peuvent commencer par cartographier chaque flux de travail qui permet à l’IA de traiter des e-mails entrants ou de récupérer le contexte d’une boîte mail.
Les équipes devraient documenter ce que chaque assistant peut lire, les outils qu’il peut appeler et les actions nécessitant une approbation. Elles devraient également tester des messages contenant du contenu caché et hors écran.
Les exercices de sécurité devraient inclure les deux directions d’attaque. Un test devrait masquer du contenu bénin pour contourner la classification. Un autre devrait masquer des instructions malveillantes destinées à l’assistant.
Les développeurs devraient évaluer si le système explique l’incertitude. Un assistant qui détecte des instructions contradictoires ou dissimulées devrait s’arrêter et identifier la source suspecte.
Les utilisateurs devraient rester sceptiques face aux avertissements générés par l’IA dans les résumés d’e-mails. Une alerte soignée peut provenir d’un contenu contrôlé par un attaquant, même lorsque l’interface appartient à un fournisseur de confiance.
Pour les flux de travail informationnels, gardez les sources originales disponibles et vérifiez les affirmations importantes avant d’agir. Les résumés d’IA devraient accélérer l’examen, et non remplacer la traçabilité.
Google News a renouvelé l’attention portée aux attaques CSS dans le webmail, mais le problème durable dépasse une seule campagne. Les e-mails transportent désormais du contenu destiné aux personnes, aux classificateurs, aux systèmes de récupération et aux outils autonomes.
Ces publics ne perçoivent pas le même message. Tant que les systèmes de sécurité ne modéliseront pas directement cette différence, les attaquants continueront d’exploiter l’écart entre ce que les humains voient et ce que les machines lisent.
