Onderzoekers hebben nieuwe CSS-aanvallen op webmail beschreven waarbij de inhoud van een e-mail niet netjes binnen de “berichtgrens” blijft. Door slimme combinaties van toegestane HTML en CSS kan die e-mail toch invloed uitoefenen op de webmailinterface van verschillende aanbieders.
In scenario’s over onder meer Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail en AOL Mail worden routes genoemd om wachtwoorden en tokens te onderscheppen, accounts over te nemen of zelfs vertrouwde UI-acties te verstoren. De publicatie bevat proof-of-conceptmateriaal en richt zich vooral op het verduidelijken van risico’s en verdedigingsmaatregelen.
Hoe kan CSS in een e-mail webmaildefensies omzeilen?
De kern van het onderzoek is dat webmail doorgaans probeert onbetrouwbare e-mailinhoud te “sanitizen” en vervolgens in de interface te renderen. Het probleem: er kan een discrepantie ontstaan tussen wat de sanitizer toestaat en wat uiteindelijk door browser of toepassing wordt opgebouwd.
Het werk onderscheidt grofweg twee manieren waarop dat mis kan gaan. Ten eerste kan misbruik worden gemaakt van HTML en CSS die webmail al toestaat. Ten tweede kan een aanvaller een situatie creëren waarin het sanitizenproces iets goedkeurt, maar later alsnog nieuwe DOM-structuren of CSS-effecten tot stand komen die buiten de verwachte grenzen vallen.
Van bericht naar “vertrouwde” interface
Voor de verdediging is vooral relevant dat de aanval “over de grens” gaat tussen een onbetrouwbaar bericht en een vertrouwde gebruikersinterface. Daardoor kunnen elementen uit de e-mail niet alleen visuele styling beïnvloeden, maar ook interacties, actieve UI-onderdelen of zelfs verzoeken naar externe diensten sturen.
In het artikel wordt bijvoorbeeld beschreven hoe het kan dat label-elementen in een Outlook-achtige keten controls buiten het bericht kunnen laten afgaan. Vervolgens kan toepassinglogica (zoals JavaScript) gesanitiseerde custom attributes omzetten in nieuwe DOM-nodes die alsnog CSS buiten de toestemmingslijst brengen. Met een extra CSS-truc kan de aanvaller vervolgens “arbitraire” CSS bereiken.
Voorbeelden uit de research: wat kan er uitlekken?
De onderzoekers koppelen de technieken aan meerdere aanvalspaden. Daarbij zijn in de publicatie verschillende ketens genoemd die telkens op een ander detailniveau ingrijpen. Belangrijk: de bron meldt dat het om proof-of-conceptonderzoek gaat en niet dat alle ketens daadwerkelijk in het wild zijn geëxploiteerd.
Outlook: een sign-in scherm nabootsen en wachtwoord vastleggen
In één Outlook/Firefox-achtige keten wordt een Microsoft-aanmeldscherm gespoofd. Vervolgens kan het systeem het wachtwoord capteren dat de ontvanger in dat nep-aanmeldscherm typt. De vraag of de volledige keten tegen dezelfde aanval inmiddels is gerepareerd, wordt in de publicatie niet eenduidig beantwoord.
Yahoo en AOL: paste-races en tokenblootstelling
Voor Yahoo Mail en AOL Mail beschrijven de onderzoekers een route waarin geplakte HTML tijdelijk actieve CSS kan behouden voordat sanitizatie plaatsvindt. In een Medium-gerelateerde demonstratie wordt een e-mail-loginflow gestart, waarna de gebruiker CSS die door een aanvaller is aangeleverd naar het klembord kopieert en vervolgens plakt in een draft.
De publicatie stelt dat daarbij voldoende informatie over een 12-characters login token kan worden blootgelegd om het token op de aanvallersserver te reconstrueren. Met dat token kan de aanvaller vervolgens mogelijk inloggen als het slachtoffer.
Gmail: van prompt injection naar token-exfiltratie
Een Gmail-achtige keten combineert CSS-gerelateerde mogelijkheden met prompt-injectie en gebruikersinteractie. In de demo-setting wordt een Slack token exfiltrated nadat een mail als bevestigingsstap in de keten wordt gebruikt. De bron koppelt dit bovendien aan een scenario waarin de geïnjecteerde instructie via een connected Gmail-connector door een AI-tool wordt verwerkt.
Hierdoor verschuift het risico van “alleen” accountovername naar ook het beïnvloeden van systemen die e-mail verwerken en samenvatten.
Wanneer e-mails AI-hulpmiddelen besmetten
Een opvallend onderdeel van het onderzoek gaat over AI-verbonden e-mail. De redenering: als een webmailomgeving de e-mailinhoud toelaat om CSS-gedrag of verborgen instructies te sturen naar een AI-verwerker, dan kan die AI onbedoeld gevoelige data ophalen of in een conceptversie plaatsen.
De publicatie beschrijft een keten rond Gmail waarin een methode zoals image-set() als fallback externe requests kan triggeren, ook als sanitizatie dat anders zou blokkeren. Vervolgens wordt het gekoppeld aan prompt injection die door Anthropic’s Claude Cowork wordt verwerkt via een “connected Gmail connector”.
Claude Cowork en het “lekken via een draft”
In de demonstratie wordt een Slack-tokenbevestigingsmail door de aanvaller gestart. Daarna vraagt het slachtoffer aan Cowork om de e-mails te verwerken. Door de geïnjecteerde instructies haalt de AI het token op en plaatst het in een HTML-draft. Door dat concept te bekijken kan het token alsnog zichtbaar of uitlegbaar worden voor de aanvaller.
Fastmail: AI-browser misleiding en “CSS hotwiring”
Fastmail-demos richten zich op misleiding van een AI-gestuurde browser. De bron noemt dat CSS pseudo-elements en opacity ervoor kunnen zorgen dat een mens ogenschijnlijk normale tekst ziet, terwijl de modelcomponent verborgen instructies leest.
Wanneer de gebruiker de AI vraagt om de zichtbare tekst te vertalen, zouden de verborgen instructies kunnen leiden tot het openen van extra tabs en het verwerken van persoonlijke informatie in URL-fragmenten.
Daarnaast meldt de publicatie “CSS hotwiring”: hiermee kan een klik worden omgeleid naar onbedoelde UI-acties of zelfs multi-step processen die niet overeenkomen met de bedoeling van de gebruiker.
Defensie: wat raden de onderzoekers webmailproviders aan?
De auteurs leggen verdedigingsprincipes vast die verder gaan dan “meer sanitizen”. Volgens de publicatie begint het met strikte isolatie: HTML e-mailinhoud moet worden gerenderd in gesandboxde iframes. Daarmee verklein je de kans dat CSS- en DOM-effecten buiten de veilige context kunnen doorwerken.
Daarna volgen aanvullende controles voor CSS. Denk aan het beperken en controleren van CSS-validatie, het actief beoordelen van “CSS gadgets” voordat custom attributes worden toegestaan, en het blokkeren van bepaalde UI-onderdelen zoals select menus en gevaarlijke selectors.
Beperk requests en sta minder externaliteiten toe
Verder adviseren de onderzoekers het verhinderen van aanvaller-gestuurde image requests en het voorkomen van problematische situaties met allow-listed domains. Voorbeelden uit de publicatie gaan ook in op proxy- of afbeeldingsroutes waarbij een allow-lijst mogelijk aanwijzingen kan lekken zodra een e-mail wordt weergegeven.
Ten slotte wordt genoemd dat sommige implementaties nog gevoelig bleken voor bepaalde gadgets toen de onderzoeker opnieuw testte. Dat benadrukt het belang van regressietests zodra patches worden doorgevoerd.
Is dit al opgelost bij alle providers?
De bron geeft geen absoluut beeld “bij iedereen opgelost”. Wel wordt genoemd dat Fastmail twee CSS-mutatieproblemen zou hebben gefixt, en dat een Proton Mail-proxy bypass niet meer werkte toen de onderzoeker het opnieuw testte.
Voor andere onderdelen—zoals label-jacking bij Outlook of bepaalde Gmail bypasses—wordt aangegeven dat sommige technieken nog werkten op het moment van publicatie. Tegelijk zegt de publicatie niet met zekerheid dat de volledige keten in alle varianten inmiddels is gestopt.
Dat maakt het verstandig om het onderwerp te zien als een categorie risico die om structurele mitigaties vraagt, niet alleen om losse reparaties.
Praktische tips voor organisaties en gebruikers
Al is het onderwerp primair gericht op webmailproviders, organisaties kunnen wel degelijk stappen zetten om impact te beperken.
- Beperk het vertrouwen in e-mailinhoud richting geautomatiseerde processen zoals AI-samenvattingen of ticketbots.
- Monitor logica rond connected apps: als e-mail een AI-tool of workflow triggert, controleer dan welke stappen gevoelige tokens kunnen opleveren.
- Stimuleer veilige gebruikersinteractie: als u instructies ontvangt om te plakken, te kopiëren of “drafts” te controleren, behandel dat als verdacht gedrag.
- Voer vendor- en platformtests uit wanneer er patches zijn voor webmail of voor integraties met AI/automatisering.
Wie het breder wil plaatsen in securityrisico’s van communicatie en interactie met systemen, kan ook kijken naar eerder berichtgeving over hoe e-mailketens en user-interactie misbruikt worden, zoals dat types van data-lekken via bedrijfsinterfaces kunnen ontstaan.
Voor een meer algemene blik op governance en hoe je cyberrisk toekomstbestendig aanpakt, is governance versus compliance in cyberrisk een nuttige aanvulling.
Waarom dit onderzoek belangrijk is
De CSS-aanvallen op webmail laten zien dat “rendering” niet hetzelfde is als “veilig”. Zelfs als een e-mailinhoud zichtbaar netjes lijkt, kan CSS-gedrag de softwarekant beïnvloeden—zeker in moderne webmailomgevingen waar veel UI-logica draait en waar e-mail steeds vaker door connected apps of AI-tools wordt gelezen.
Het onderzoek maakt daarnaast duidelijk dat mitigaties vooral moeten focussen op isolatie, strikte validatie van styling, en het voorkomen van boundary-crossing tussen onbetrouwbare content en vertrouwde interface-elementen.
Conclusie: e-mail blijft een aanvalsvector, maar deze keer niet alleen via klassieke phishing of scripts. Met technieken die HTML/CSS laten “weglekken” naar de interface kan er risico ontstaan op wachtwoord- en tokenlekken, en op manipulatie van AI-gestuurde workflows. Voor providers is het aanpakken van isolatie en CSS-bescherming prioriteit; voor organisaties is het zaak om connected e-mailprocessen kritisch te evalueren.
Bron: https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html
