Attaques CSS webmail : comment des emails piégés volent mots de passe et tokens en 2026

Et si un simple email, sans pièce jointe malveillante ni lien suspect, pouvait capturer votre mot de passe Outlook ? C’est la démonstration choc faite par le chercheur Gareth Heyes (PortSwigger) lors de la conférence Black Hat USA 2026. Ses travaux révèlent une nouvelle génération d’attaques CSS webmail capables de franchir les barrières de sécurité des messageries les plus utilisées au monde : Outlook, Gmail, Yahoo Mail, Proton Mail, Fastmail et AOL Mail.

Selon le rapport annuel de l’ANSSI sur la menace informatique, les attaques ciblant les messageries professionnelles ont augmenté de 40 % en 2025. Ces nouvelles techniques ajoutent une couche de sophistication inédite. Elles ne reposent pas sur une pièce jointe ou un lien, mais sur le code même qui met en forme l’email. L’impact potentiel est massif : vol de mot de passe, prise de contrôle de compte, fuite de tokens d’authentification et manipulation d’assistants IA. Cet article décortique le fonctionnement de ces vulnérabilités CSS webmail et détaille les mesures de protection à adopter dès maintenant.

Comprendre le principe des attaques CSS webmail

Le postulat de base est simple : le contenu d’un email est considéré comme non fiable, tandis que l’interface du webmail est fiable. Les attaques CSS webmail visent à créer un pont entre ces deux mondes. Le chercheur de PortSwigger a exploré deux voies principales.

La première voie, dite « abuse of allowed features », consiste à utiliser des éléments HTML et CSS que le webmail autorise dans un but détourné. Par exemple, les éléments <label> sont souvent autorisés pour l’accessibilité, mais ils peuvent être détournés pour interagir avec des contrôles de l’interface du webmail (label jacking).

Toutefois, la seconde voie, plus subtile, exploite les « parsing differences ». Le sanitizer du webmail analyse le code HTML et CSS selon ses propres règles, mais le navigateur de l’utilisateur peut l’interpréter différemment. Cette divergence permet d’injecter du code malveillant que le sanitizer n’a pas détecté. C’est ce que l’on appelle une attaque de type « mutation XSS » (mXSS) appliquée au CSS.

“L’objectif est de créer une divergence entre ce que le sanitizer autorise et ce que le navigateur interprète.” - Gareth Heyes, PortSwigger.

En pratique, ces attaques contournent le modèle de sécurité des webmails. Elles ne nécessitent pas de cliquer sur un lien, mais simplement d’ouvrir l’email ou, dans certains cas, d’interagir avec son contenu de manière apparemment anodine. L’ANSSI, dans ses guides de sécurisation des messageries, insiste sur l’importance de l’isolation des contenus, mais ces nouvelles techniques montrent que les mesures actuelles sont insuffisantes.

Les chaînes d’attaque dévoilées à Black Hat USA 2026

Gareth Heyes a présenté plusieurs chaînes d’attaque complètes, ciblant des webmails spécifiques et exploitant des comportements uniques de navigateurs comme Firefox. Voici les plus marquantes.

Vol de mot de passe Outlook via Firefox

L’attaque la plus spectaculaire cible Outlook sur le navigateur Firefox. La chaîne combine plusieurs techniques CSS. D’abord, le label jacking permet de détourner des éléments <label> pour interagir avec des contrôles de l’interface Outlook situés en dehors du message. Ensuite, l’application JavaScript d’Outlook transforme des attributs personnalisés sanitizés en nouveaux nœuds DOM, ce qui permet d’injecter du CSS non filtré.

Une astuce de parsing de media queries offre ensuite à l’attaquant un contrôle total du CSS. L’élément clé est un <select> déguisé en champ de mot de passe. Firefox réinitialise son timer de sélection d’une seconde lorsque l’élément passe hors de l’écran, ce qui rend la capture des frappes quasi instantanée. Le résultat est un écran de connexion Microsoft parfaitement imité qui enregistre le mot de passe saisi par la victime.

Fuite de token par « paste race » sur Yahoo et AOL

Une autre technique, baptisée « paste race », exploite le délai entre le collage d’un contenu HTML et sa sanitization par le webmail. Sur Yahoo Mail et AOL Mail, le CSS injecté via un collage reste actif quelques millisecondes.

“Le CSS permet de dire une chose à l’humain et une autre à la machine.”

Dans la démonstration, l’attaquant initie un flux de connexion par email (par exemple, pour Medium). La victime copie le code CSS fourni par l’attaquant et le colle dans un brouillon Yahoo ou AOL. Pendant le court instant où le CSS est actif, des requêtes sont envoyées vers le serveur de l’attaquant, révélant le token de connexion caractère par caractère. Celui-ci peut ensuite être reconstitué pour prendre le contrôle du compte de la victime.

Manipulation des IA de messagerie (Gmail/Cowork et Fastmail/Atlas)

En outre, l’essor des assistants IA capables de lire et de traiter les emails ouvre une nouvelle surface d’attaque. L’attaquant ne cible plus l’humain, mais l’IA qui lit l’email à sa place.

Sur Gmail, la fonction CSS image-set() permet de définir des images de secours. Bien que Gmail bloque les images externes, le fallback image-set() peut être utilisé pour initier une requête HTTP vers un serveur malveillant. Le chercheur a combiné cette technique à une injection de prompt indirecte dans un email traité par Claude Cowork (Anthropic). En demandant à Cowork de traiter ses emails, la victime déclenche involontairement l’exécution des instructions cachées. L’IA est alors amenée à récupérer un token Slack et à le placer dans un brouillon HTML, dont la visualisation par l’attaquant provoque la fuite.

Sur Fastmail, une attaque similaire ciblait OpenAI Atlas. Des pseudo-éléments CSS et des réglages d’opacité permettaient de masquer des instructions à l’utilisateur tout en les rendant parfaitement lisibles par l’IA. Lorsque l’utilisateur demandait à Atlas de traduire le texte visible, les instructions cachées lui ordonnaient d’ouvrir des onglets et d’encoder des données dans des fragments d’URL.

Ces manipulations d’assistants IA rappellent d’autres failles critiques dans les outils d’intelligence artificielle, où des données sensibles de réunions ont été exposées.

Techniques CSS et vecteurs d’attaque détaillés

Les attaques CSS webmail reposent sur un arsenal de techniques fines. Voici les principales identifiées par la recherche.

Liste des techniques CSS exploitées :

• Label Jacking : Détournement des éléments HTML <label> pour interagir avec des contrôles situés en dehors de la zone de l’email.
• CSS Mutation : Exploitation d’attributs personnalisés (data-*) pour créer de nouveaux nœuds DOM contenant du CSS non filtré par le sanitizer.
• Media Query Parsing : Utilisation de requêtes média CSS pour obtenir un contrôle arbitraire des styles, en contournant les listes blanches.
• Image-set() Bypass : Contournement du proxy d’images de Gmail via la propriété CSS image-set() et ses polices de secours.
• Paste Race : Exploitation du délai de sanitization lors du collage de contenu HTML dans un brouillon (Yahoo, AOL).
• Exfiltration par clic : Technique où le CSS analyse un token numérique affiché, masque les liens incorrects et ne laisse visible que le bon, forçant un clic de l’utilisateur qui envoie les données à l’attaquant.

Tableau comparatif des attaques CSS webmail :

Ce tableau montre la diversité des vecteurs. Chaque webmail présente des failles spécifiques que les attaquants peuvent exploiter. La défense doit donc être globale et ne pas se limiter à un seul fournisseur.

Mesures de protection pour les entreprises et les utilisateurs

Face à ces menaces, la réaction des éditeurs a été variable. Fastmail a corrigé deux bugs de mutation CSS. Proton Mail a vu son proxy contourné, mais la faille a été colmatée. Outlook et Gmail travaillent sur des correctifs durables. En attendant, les entreprises et les utilisateurs doivent adopter une posture de défense active.

Recommandations pour les fournisseurs et les DSI :

Les recommandations issues de la recherche PortSwigger et des bonnes pratiques de l’ANSSI sont claires. Voici les mesures à implémenter prioritairement.

1. Isolation stricte du contenu HTML : Utiliser des iframes sandboxées pour afficher les emails. Cela empêche le CSS et le JavaScript de l’email d’interagir avec l’interface principale du webmail.
2. Restriction des propriétés CSS : Mettre en place une liste blanche des propriétés CSS autorisées. Bloquer les sélecteurs dangereux (:has(), :contains()), les media queries complexes, et les attributs personnalisés (data-*).
3. Contrôle des requêtes externes : Imposer un proxy pour toutes les images et ressources externes. Bloquer les domaines non autorisés et les schémas d’URI rares.
4. Désactiver les éléments de formulaire : Bloquer l’utilisation des éléments <input>, <select>, <textarea> et <label> dans les emails. Ces éléments n’ont pas leur place dans un message.
5. Mettre à jour les navigateurs et les webmails : Les correctifs de sécurité sont déployés régulièrement. S’assurer que les postes de travail utilisent des versions à jour de Firefox, Chrome et Edge.
6. Sensibiliser les utilisateurs : Former les employés à ne pas copier/coller de contenu HTML suspect dans leur webmail et à être vigilants face aux demandes de connexion inattendues.
7. Auditer les politiques CSP : Vérifier que la Content Security Policy du webmail est suffisamment restrictive.

Exemple de politique CSP pour un webmail :

Content-Security-Policy:
  default-src 'self';
  img-src 'self' https://proxy.email-provider.com;
  style-src 'self' 'unsafe-inline' https://assets.email-provider.com;
  form-action 'none';
  frame-src 'none';
  connect-src 'self';

Note : L’utilisation de 'unsafe-inline' pour les styles est souvent nécessaire pour le rendu des emails, mais elle ouvre la porte aux attaques CSS. L’idéal est d’utiliser un nonce ou un hash, mais cela reste complexe à mettre en œuvre pour du contenu dynamique. La priorité est donc l’isolation par iframe, associée à un firewall-as-a-service adapté aux besoins de l’entreprise pour garantir une protection multicouche.

Cas concret : une ETI française face à la menace

Prenons l’exemple d’une ETI française de 500 employés utilisant Microsoft 365. Son RSSI a mis en place une politique de sécurité rigoureuse : filtrage antispam, blocage des pièces jointes exécutables, authentification multifacteur. Pourtant, une attaque CSS webmail ciblant Outlook pourrait contourner toutes ces défenses. Un email contenant un code CSS malveillant arrive dans la boîte de réception d’un employé. Celui-ci ouvre l’email, et le code interagit avec l’interface Outlook pour afficher un faux écran de connexion. L’employé saisit son mot de passe, qui est immédiatement envoyé à l’attaquant. La MFA est contournée car l’attaquant dispose des identifiants en temps réel.

Pour se protéger, le RSSI doit travailler avec son fournisseur de messagerie pour implémenter les recommandations de PortSwigger. L’isolation par iframe sandboxée est la mesure la plus efficace. En attendant, la désactivation des éléments <select> et <label> dans les emails peut réduire la surface d’attaque.

Conclusion : une nouvelle ère pour la sécurité des emails

Les attaques CSS webmail présentées par Gareth Heyes marquent un tournant dans la perception de la sécurité des messageries. Elles démontrent que le CSS, souvent relégué au rang de langage de présentation inoffensif, peut devenir un vecteur d’attaque redoutable lorsqu’il est combiné à des failles de navigateur et à des lacunes de sanitization. L’histoire de la sécurité numérique montre que les vulnérabilités de portefeuilles matériels peuvent également avoir des conséquences financières dévastatrices.

Pour les RSSI et les DSI français, l’heure est à la vigilance. La mise à jour des politiques de sécurité des messageries est impérative. L’isolation des contenus, le contrôle strict des CSS et la mise à jour des navigateurs sont les piliers de la défense contre ces nouvelles menaces.

Alors que les fournisseurs de webmail déploient des correctifs, la responsabilité incombe aussi aux utilisateurs. La prochaine fois que vous ouvrirez un email, souvenez-vous que son apparence soignée peut cacher un code malveillant conçu pour voler vos identifiants. En 2026, la sécurité des webmails ne se joue plus seulement sur le filtrage des pièces jointes, mais sur la moindre ligne de CSS. Restez informés et protégés.