Bei vielen Angriffen im E-Mail-Umfeld denken Sicherheitsverantwortliche zuerst an klassische Phishing-Taktiken oder bösartige Anhänge. Neue Forschung rückt jedoch etwas anderes in den Fokus: CSS-Angriffe im Webmail. Dabei kann gestalteter Inhalt aus einer E-Mail die eigentlich getrennte Weboberfläche stören – mit Folgen, die von Token-Leaks bis hin zu manipulierter Interaktion reichen.
Die Ergebnisse stammen aus Arbeiten, die auf Black Hat USA 2026 vorgestellt wurden. Der Sicherheitsforscher Gareth Heyes beschreibt, wie bestimmte Kombinationen aus erlaubtem HTML, CSS-Verhalten und Browser-Logik eine Grenze zwischen „untrusted message“ und „trusted interface“ überschreiten können. In mehreren bekannten Webmail-Diensten werden verschiedene Pfade demonstriert – teils mit Proof-of-Concepts.
Wichtig: Die Studie berichtet keine vollständig dokumentierten, realen Missbrauchsszenarien. Gleichzeitig bleiben öffentliche PoCs laut Bericht bis zum 8. August verfügbar, also sollte man die Erkenntnisse ernst nehmen.
Wie CSS in E-Mails Schutzgrenzen überwindet
Grundidee der Forschung ist, dass Webmail-Plattformen E-Mail-Inhalte zunächst „sanitizen“ – also bereinigen. Danach verarbeitet jedoch nicht nur die Sanitizer-Logik den Inhalt, sondern am Ende müssen Browser und Webmail-UI Regeln zur Darstellung und Interaktion anwenden. Wenn dabei eine Diskrepanz entsteht, kann der Bereinigungsvorgang die Kontrolle verlieren.
Zwei Wege werden dabei besonders hervorgehoben:
- Missbrauch dessen, was Webmail bereits erlaubt: Wenn HTML- und CSS-Strukturen zugelassen sind, können daraus unerwartete Effekte entstehen.
- Abweichung zwischen Sanitizer und finaler DOM-Erzeugung: Wenn der Sanitizer etwas für harmlos hält, aber Browser oder Anwendung später doch mehr daraus machen, kann die Nachricht „in“ die vertrauenswürdige Oberfläche hineinwirken.
Aus der Forschung folgt: Es reicht nicht, nur „alles zu bereinigen“. Entscheidend ist, wie der restliche Content in einer isolierten Umgebung dargestellt wird und welche CSS-Funktionen dabei wirklich kontrolliert werden.
Beispiele aus Outlook, Gmail & Co.: Von Passwort- bis Token-Diebstahl
Die Studie skizziert Angriffsketten, die mehrere Dienste betreffen, darunter Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail und AOL Mail. Die Zielrichtung reicht dabei von Kontenübernahmen über das Auslesen von Tokens bis zur Beeinflussung externer, verbundenen Workflows.
Outlook: gefälschte Anmeldemaske und Passwortabgriff
In einer beschriebenen Outlook/Firefox-Kette kann eine Fehlleitung auf eine Microsoft-Anmeldeseite aussehen. Ein zentraler Punkt: Der Empfänger tippt ein Passwort in eine gespoofte Eingabemaske, während der Angreifer die Eingabe abgreifen kann.
Ob diese konkrete vollständige Kette inzwischen geschlossen wurde, bleibt laut Bericht jedoch offen. Einige andere Outlook-bezogene Mechanismen wurden zum Zeitpunkt der Veröffentlichung noch als funktionierend beschrieben.
Yahoo Mail und AOL Mail: Token durch „Paste“-Rennen
Für Yahoo Mail und AOL Mail zeigt die Forschung einen anderen Pfad. Ein „paste race“-Szenario ermöglicht, dass während eines engen Zeitfensters bestimmte aktive CSS-Elemente nicht sofort vollständig bereinigt sind.
Im Medium-Setup wird zudem beschrieben, dass der Angreifer eine E-Mail-Login-Passage anstößt. Anschließend soll der Empfänger CSS vom Angreifer in die Zwischenablage kopieren und es dann in einen Yahoo- oder AOL-Entwurf einfügen. Über die resultierenden Anfragen kann ein Angreifer ausreichen Teile eines login token rekonstruieren – einem Token, das später für den Einstieg als Opfer genutzt werden kann.
Gmail: Exfiltration über Prompt-Injection und Nutzerinteraktion
Eine Gmail-basierte Kette soll es erlauben, nach Prompt-Injection und gezielter Nutzeraktion einen Slack-Token zu exfiltrieren. Das gelingt, indem der Angriff über Zwischenschritte den richtigen Moment für die Übermittlung herstellt.
Damit wird sichtbar, dass selbst scheinbar harmlose E-Mail-Darstellungen eine Rolle in größeren Angriffsketten spielen können – insbesondere dann, wenn Nutzer oder Tools Interaktionen ausführen, die dem Angreifer Kontrolle über Parameter geben.
Auch „geschützte“ Bereiche: UI-Aktionen, Mediendiagramme und Timing-Tricks
Ein wiederkehrendes Muster ist, dass erlaubte Elemente aus der E-Mail die Webmail-UI beeinflussen können. Die Studie nennt dabei u. a. Mechanismen, bei denen erlaubte Label-Elemente außerhalb der Nachricht liegende Kontrollen auslösen.
Zusätzlich werden Techniken beschrieben, die es erlauben, CSS über „unvorhergesehene“ DOM-Erzeugung zu erweitern. Ein weiteres Detail: Bestimmte Browser-Logiken beim Umgang mit UI-Elementen – einschließlich Timing rund um Auswahlen – können dabei helfen, dass ein Capture im entscheidenden Moment möglich wird.
In der Praxis heißt das: Wer nur auf einzelne Sanitizer-Regeln schaut, übersieht möglicherweise, wie sich verschiedene Komponenten im Zusammenspiel verhalten.
Click-basierte Exfiltration, wenn externe Ressourcen blockiert werden
Ein weiterer Teil der Forschung adressiert Fälle, in denen eine Content Security Policy (CSP) externe Ressourcen blockiert. Das Ziel bleibt jedoch: Daten aus der E-Mail sollen dennoch auslesbar werden.
Die Idee: Wenn ein Token als Text im E-Mailinhalt gerendert wird und CSS so manipuliert werden kann, dass nur bestimmte Stellen sichtbar/benutzbar sind, kann CSS entscheiden, welche Ziffern vorkommen und wie oft.
Der Clou ist, dass nicht per klassischer Webrequest exfiltriert werden muss. Stattdessen kann eine anklickbare Darstellung so gestaltet werden, dass ein Klick diese Informationen an den Angreifer überträgt.
AI-verbundene E-Mails: Wenn Modelle versteckte Anweisungen übernehmen
Besonders kritisch wirkt, was die Studie über „AI-connected email“ beschreibt. Hier geht es weniger um das reine Anzeigen einer E-Mail, sondern darum, dass Tools oder Assistants E-Mail-Inhalte weiterverarbeiten – manchmal über Connectoren.
Gmail & Claude Cowork: Tokens landen in Entwürfen
In einem demonstrierten Setup wird eine indirekte Prompt-Injection mit einem verbundenen Workflow gekoppelt. Nach einer Token-Bestätigungsmail für Slack soll der Empfänger die E-Mails über einen KI-Workflow verarbeiten. Die injizierten Anweisungen führen dazu, dass das Tool einen Token aus der Nachricht in einen HTML-Entwurf übernimmt. Das spätere Anzeigen dieses Entwurfs kann wiederum den Token leaken.
Damit zeigt die Forschung: Sobald KI-Workflows E-Mail-Inhalte „verstehen“ und in neue Dokumente oder Entwürfe übernehmen, kann unsauber isolierter Content Ketten verstärken.
Fastmail & Atlas AI: versteckte Prompts via CSS-Pseudoelemente
In einer Fastmail-Demo wird eine Browser-KI namens Atlas AI in den Mittelpunkt gestellt. Über CSS-Pseudoelemente und Opazitäts-Mechaniken soll ein Mensch nur harmlos wirkenden Text sehen, während das Modell versteckte Anweisungen verarbeitet.
Wenn der Nutzer anschließend etwa eine Übersetzungsanfrage stellt, kann der versteckte Prompt dafür sorgen, dass Atlas neue Tabs öffnet und Daten in URL-Fragmenten kodiert – unter anderem mit dem Namen des Opfers.
Der Bericht erwähnt zudem, dass OpenAI Atlas deprecatet und den Stopp der Funktionalität auf den 9. August 2026 terminiert.
Was sagt die Studie zur Abwehr?
Der Bericht geht nicht nur auf Angriffswege ein, sondern nennt auch konkrete Empfehlungen. Der Fokus liegt auf konsequenter Isolation und auf restriktiven Regeln für CSS und anwendungsseitige Features.
Wichtige Punkte aus der defensiven Guidance:
- Strikte Isolation: HTML-E-Mails sollten in sandboxed iframes dargestellt werden.
- CSS streng einschränken: Die Studie empfiehlt eine sehr genaue Validierung und die Nutzung von Character Allow Lists für CSS.
- Custom Attributes absichern: Prüfen, ob „CSS gadgets“ vorhanden sind, bevor benutzerdefinierte Attribute zugelassen werden.
- Gefährliche UI-Elemente blockieren: Dazu zählen u. a. Select Menus und gefährliche Selektoren.
- Attacker-kontrollierte Bildanfragen verhindern: Insbesondere sollte man verhindern, dass Bilder oder Anfragen in erlaubte Domains „durchrutschen“.
Zusätzlich werden mehrere Fastmail- und Proton-Mail-relevante Beobachtungen erwähnt, darunter Fixes bei CSS-Mutation-Bugs sowie ein Proton-Proxypass-Problem, das bei einer erneuten Prüfung nicht mehr funktionierte. Für Proton wird außerdem ein separater Vector genannt, der die IP-Adresse der Empfängerin oder des Empfängers offenlegen kann, wobei das genaue Timing in Zusammenhang mit Tracking-Schutzmechanismen stehen kann.
Warum das für Betreiber und Nutzer zählt
Für Webmail-Anbieter ist die zentrale Botschaft: Es ist nicht ausreichend, nur „saubere“ Ausgabe zu erzeugen. Entscheidend ist, wie Inhalte im Browser und in der Webmail-UI nach dem Sanitizing wirken, etwa über CSS-Parsing, DOM-Erzeugung und Interaktionspfade.
Für Nutzer bedeutet es zwar nicht, dass jede Mail sofort gefährlich ist, aber die Forschung zeigt: Sorglosigkeit bei Einfügen, Interaktion oder dem Umgang mit Content aus E-Mails kann in Angriffsketten eine Rolle spielen. Besonders kritisch wird es, wenn E-Mails mit Connectoren, Entwürfen oder KI-Workflows verbunden sind.
Fazit
CSS-Angriffe im Webmail demonstrieren, wie E-Mail-Inhalt die Grenze zur vertrauenswürdigen Oberfläche überschreiten kann – insbesondere über Kombinationen aus HTML/CSS-Erlaubnissen, Sanitizer-Lücken und UI-Logik. Die Bandbreite reicht von Passwortabgriffen und Token-Leaks bis zu manipulierter Verarbeitung in KI-gestützten Workflows.
Die Studie liefert dabei klare Verteidigungsideen: starke Isolation in sandboxed iframes, restriktive CSS-Regeln, strenge Prüfungen vor dem Erzeugen/Weiterreichen von DOM-Elementen sowie das Blockieren riskanter Selektoren, UI-Controls und attacker-kontrollierter Bildanfragen.
Quelle: https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html
