Attaques CSS contre les webmails : comment les pirates contournent les défenses en 2026

Et si un simple email pouvait s’extraire de sa propre interface pour voler vos mots de passe ? C’est le scénario glaçant dévoilé par le chercheur Gareth Heyes (PortSwigger) lors de la conférence Black Hat USA 2026. Ses recherches démontrent que des attaques CSS sophistiquées ciblant les webmails les plus populaires (Outlook, Gmail, Proton Mail, Yahoo, Fastmail, AOL) permettent de capturer des identifiants, de détourner des tokens d’authentification et même de manipuler des assistants IA connectés à votre boîte mail. Cet article décortique ces vulnérabilités CSS, explique les mécanismes techniques et vous propose des pistes de défense concrètes pour sécuriser votre messagerie professionnelle face à ces nouvelles menaces.

Le constat alarmant : des attaques CSS ciblant les webmails les plus populaires

La recherche présentée par Gareth Heyes bouleverse le paradigme de sécurité des emails. Jusqu’à présent, on considérait que le contenu d’un message était confiné à sa fenêtre d’affichage. Les travaux publiés le 6 août 2026 démontrent le contraire : le contenu d’un email peut franchir la frontière de son message et interagir avec l’interface du webmail.

Les six plus grands fournisseurs de messagerie sont concernés. Contrairement aux idées reçues, ces attaques ne reposent pas sur une faille de sécurité classique comme une injection SQL ou un cross-site scripting (XSS) direct. Elles exploitent les fonctionnalités mêmes du CSS et du HTML autorisées par les webmails, ou bien un écart entre ce que le sanitizer approuve et ce que le navigateur interprète.

“Ces travaux montrent que la frontière entre le contenu non fiable d’un email et l’interface de confiance du webmail peut être franchie.”

Les conséquences sont multiples : vol de mot de passe (Outlook/Firefox), prise de contrôle de comptes tiers (Yahoo/AOL), fuite de tokens d’authentification Slack (Gmail), ou encore détournement d’agents IA comme Claude d’Anthropic ou OpenAI Atlas. Selon le chercheur, les preuves de concept (PoC) sont publiques depuis le 8 août 2026, ce qui augmente considérablement le risque d’exploitation dans la nature.

Anatomie des attaques : comment le CSS devient une arme

Le détournement de l’interface (label-jacking) sur Outlook

La première chaîne d’attaque, baptisée label-jacking, cible les utilisateurs d’Outlook sur Firefox. L’élément HTML <label> est traditionnellement utilisé pour associer un texte à un champ de formulaire. Dans le contexte d’Outlook, il peut déclencher des contrôles situés en dehors du message. Le JavaScript de l’application peut transformer des attributs personnalisés, pourtant autorisés par le sanitizer, en nouveaux nœuds DOM portant du CSS hors de la liste blanche. Un tour de passe-passe de media-query parsing offre ensuite à l’attaquant un CSS arbitraire.

<!-- Exemple conceptuel de label-jacking -->
<label for="passwordSelect">Cliquez ici pour lire l'email</label>
<select id="passwordSelect" style="position:absolute;left:-9999px;">
  <option value="M0td2P@sse">Mot de passe capturé</option>
</select>

La chaîne déguise un élément <select> en champ de mot de passe. Firefox réinitialise son minuteur d’option lorsque le select se déplace hors écran, rendant la capture en temps réel. L’attaquant peut ainsi afficher une fausse page de connexion Microsoft et capturer le mot de passe saisi par la victime.

La course au collage (paste race) sur Yahoo et AOL

Une technique différente a été découverte sur Yahoo Mail et AOL Mail. Dans Firefox, le HTML collé peut brièvement conserver un CSS actif avant la sanitization. La technique du paste race est particulièrement insidieuse car elle exploite une fenêtre de tir très courte. Lorsque l’utilisateur colle du contenu, le navigateur tente d’appliquer le formatage. Si le contenu collé contient des règles CSS, celles-ci sont actives pendant quelques millisecondes avant que le sanitizer ne les neutralise. Pendant cette fenêtre, les requêtes CSS (comme background-image: url()) peuvent être déclenchées, envoyant des données au serveur de l’attaquant.

Dans la démonstration visant Medium, l’attaquant initie un flux de connexion par email. La victime copie le CSS fourni par l’attaquant, puis le colle dans un brouillon Yahoo ou AOL. Les requêtes résultantes révèlent une partie du token de connexion de 12 caractères, permettant au serveur de l’attaquant de le reconstituer et de se connecter à la place de la victime.

L’injection de prompt indirecte dans les assistants IA

La connexion des webmails aux IA génératives ouvre une nouvelle surface d’attaque. L’email d’injection indirecte est traité par Claude Cowork via un connecteur Gmail. Les instructions injectées amènent l’IA à extraire un token Slack et à le placer dans un brouillon HTML. La simple visualisation du brouillon par la victime provoque la fuite du token.

Chez Fastmail, une démonstration ciblait OpenAI Atlas. Des pseudo-éléments CSS et l’opacité faisaient voir un texte anodin à l’humain tandis que le modèle lisait des instructions cachées. Lorsque l’utilisateur demandait à Atlas de traduire le texte visible, l’invite cachée lui faisait ouvrir des onglets et encoder le nom de la victime dans des fragments d’URL. OpenAI a depuis annoncé la dépréciation d’Atlas, prévue pour le 9 août 2026.

Les failles techniques exploitées par les chercheurs

L’écart entre le sanitizer et le navigateur

La recherche suit deux chemins : abuser du HTML et CSS déjà autorisé par le webmail, ou créer un écart entre ce que le sanitizer approuve et ce que le navigateur crée. Ce dernier cas est le plus dangereux car il exploite une divergence d’interprétation. Outlook illustre parfaitement cette technique : des attributs personnalisés sanitizés sont transformés en nouveaux nœuds DOM par le JavaScript de l’application, créant des éléments que le filtre initial n’avait pas anticipés.

Les mutations CSS et le contournement de proxy

Fastmail a corrigé deux bugs de mutation CSS. Proton Mail a vu son contournement de proxy bloqué, mais la technique exposait l’adresse IP du destinataire. La documentation actuelle de Proton sur la protection des trackers indique que le service est conçu pour masquer l’adresse IP personnelle et l’heure exacte d’ouverture de l’email. Cette faille démontrait une limitation de cette protection.

Gmail a vu son contournement de image-set() fonctionner encore lors de la publication. Cette fonction CSS permet de spécifier différentes images pour différents contextes. En l’utilisant comme fallback, l’attaquant pouvait forcer une requête externe malgré la sanitization.

L’exfiltration basée sur le clic (click-based exfiltration)

Une technique innovante contourne les Content Security Policy (CSP) qui bloquent les ressources externes. L’attaquant injecte un style qui analyse le contenu textuel de l’email. Par exemple, si un token A3B8C2 est affiché, le CSS peut créer des liens pour chaque chiffre possible, mais ne rendre cliquable que le lien correspondant au chiffre à une position donnée. L’utilisateur, en cliquant sur ce lien, envoie une requête à l’attaquant. En répétant l’opération pour chaque position, l’attaquant reconstitue le token sans jamais avoir besoin de déclencher une requête directe.

Comment se protéger ? Recommandations pour les fournisseurs et les utilisateurs

Recommandations pour les fournisseurs de webmail

“L’isolation stricte, puis les listes blanches de caractères pour la validation CSS, la vérification des gadgets CSS avant d’autoriser les attributs personnalisés…” résume le papier de recherche.

Les mesures défensives préconisées sont claires :

1. Isoler le HTML dans des iframes sandboxées pour empêcher toute interaction avec l’interface parente.
2. Restreindre les attributs CSS autorisés à une liste blanche de caractères et de propriétés.
3. Bloquer les sélecteurs dangereux ([attr*=value], etc.) et les menus <select>.
4. Contrôler les requêtes d’images et les domaines autorisés à être chargés.
5. Auditer les gadgets CSS avant d’autoriser des attributs personnalisés dans le HTML.

Les Content Security Policy (CSP) sont un rempart important, mais elles ne sont pas une panacée. Comme le montre la technique d’exfiltration par clic, un attaquant peut contourner une CSP bien configurée si l’injection de style est possible. La combinaison d’une CSP stricte, d’une isolation par iframe sandboxée et d’une validation rigoureuse du HTML/CSS est indispensable.

Actions concrètes pour les entreprises et les RSSI

Les entreprises françaises ne sont pas à l’abri. Voici les actions à mener immédiatement :

• Auditer les solutions de messagerie : Vérifier si vos fournisseurs (Microsoft 365, Google Workspace, Proton, etc.) ont appliqué les correctifs suite à ces divulgations.
• Sensibiliser les utilisateurs : Les informer des risques liés aux emails HTML, même s’ils semblent provenir de l’interface du webmail lui-même. Un email peut désormais usurper l’interface de connexion.
• Mettre à jour les navigateurs : Firefox est particulièrement ciblé par les techniques de label-jacking et de paste race. Les correctifs navigateurs peuvent atténuer certains vecteurs.
• Segmenter les accès IA : Ne pas connecter d’IA générative aux boîtes mail sans une analyse de risques approfondie et un cloisonnement strict des données.
• Appliquer les recommandations de l’ANSSI : La sécurité des messageries est un pilier de la défense en profondeur. Les guides de l’ANSSI doivent être mis à jour pour intégrer ces nouveaux vecteurs CSS.

Exemple concret : Une PME française utilisant Gmail et Slack doit prendre conscience que la connexion de son IA Cowork à sa boîte mail crée une nouvelle surface d’attaque. Selon le RGPD, une fuite de token d’authentification menant à un accès non autorisé à un compte professionnel constitue une violation de données personnelles devant être notifiée à la CNIL sous 72 heures.

L’impact sur la conformité et la souveraineté numérique en France

Ces attaques posent un défi majeur à la conformité RGPD et aux objectifs de souveraineté numérique de l’ANSSI. Le risque de fuite de tokens d’authentification ou de mots de passe via une simple lecture d’email oblige les DPO et RSSI à revoir leur analyse de risques. L’ANSSI, dans ses guides de sécurisation des messageries, insiste sur la nécessité de filtrer les pièces jointes et de contrôler les exécutions de script. Cependant, ces nouvelles attaques CSS montrent que le filtrage doit s’étendre au contenu HTML lui-même.

La défense en profondeur devient une nécessité absolue. Il ne suffit plus de se protéger contre les malwares et le phishing. Il faut désormais considérer l’interface du webmail elle-même comme une surface d’attaque potentielle. Les entreprises certifiées ISO 27001 devront intégrer ces nouveaux vecteurs dans leur analyse de risques et leurs tests d’intrusion.

Conclusion : repenser la sécurité des webmails face aux attaques CSS

Les attaques CSS contre les webmails ne sont plus une simple curiosité académique. Elles représentent une menace tangible et immédiate pour la sécurité des entreprises et des particuliers. La balle est dans le camp des éditeurs, mais les utilisateurs et les RSSI doivent exiger des comptes et appliquer les correctifs.

Imaginez un instant que la simple lecture d’un email dans votre boîte Outlook expose le mot de passe de votre compte administrateur Microsoft 365. C’est exactement ce que permet la technique de label-jacking démontrée par Gareth Heyes. Ce n’est plus de la science-fiction.

L’email, pilier de la communication d’entreprise, doit voir son modèle de sécurité repensé de fond en comble. La prochaine action ? Surveiller les mises à jour de vos webmails et auditer vos configurations de sécurité dès aujourd’hui pour anticiper ces risques émergents.