# Your Email Client Is Lying to You: CSS Chains That Steal Passwords from Outlook, Gmail, and Yahoo
The security model behind webmail has always rested on a quiet assumption: that what arrives in your inbox stays in your inbox. An untrusted message rendered inside a trusted interface should not be able to reach out and touch that interface. Gareth Heyes, a researcher at PortSwigger, just spent a Black Hat USA presentation systematically dismantling that assumption across six of the most popular webmail providers on the planet.
The work is not theoretical. There are working exploit chains, demonstrated against production deployments, targeting real accounts on Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail. Several chains remain unpatched.
## The Sanitizer Lie
To understand what Heyes found, you need to understand what webmail providers are actually doing when they render your inbox. HTML email arrives, a sanitizer strips what it considers dangerous, and what's left gets rendered inside the provider's interface. The whole model depends on the sanitizer's allow-list being the final word on what ends up in the DOM.
It isn't.
Heyes identifies two routes around this. The first is straightforward: abuse what the sanitizer already permits. HTML and CSS that pass the allow-list can still interact with interface elements outside the message boundary if the webmail application is not careful about isolation. The second is more unsettling — create a discrepancy between what the sanitizer approves and what the browser ultimately builds. Sanitizers operate on static HTML. Browsers are dynamic, and certain combinations of allowed elements trigger DOM mutations or CSS rules that the sanitizer never evaluated.
The Outlook chain is the most elaborate illustration. Allowed label elements can trigger interface controls outside the message. Application JavaScript converts sanitized custom attributes into new DOM nodes with CSS the sanitizer never examined. A media-query parsing quirk then grants arbitrary CSS. The net effect: a select element disguised as a password field, positioned to overlap a spoofed Microsoft sign-in prompt. When the victim types their password, Firefox's roughly one-second option-selection timer is reset each time the element moves offscreen — making capture continuous rather than a single grab. Whether Microsoft has patched the full chain as of this writing is not confirmed.
## Paste, Race, Token
The Yahoo Mail and AOL Mail attack takes a different shape. In Firefox, pasted HTML briefly retains active CSS before sanitization completes. That window is enough. Heyes demonstrated an attack targeting Medium's email-login flow: the victim copies attacker-supplied CSS to the clipboard and pastes it into a draft. The resulting requests leak enough of the 12-character login token for the attacker's server to reconstruct it. No malware. No phishing link to click. Just paste.
For environments where Content Security Policy blocks external resource requests entirely, Heyes introduced a click-based exfiltration technique. Given style injection and a numeric token rendered as text, CSS can determine which digits appear and how often, hide non-matching links, and leave the one matching link spanning the page. A victim click — on what appears to be ordinary content — transmits the digit frequency data outbound.
## When the AI Reads Your Mail
The most consequential section of the research is the one that will age worst for the industry. AI-connected email creates an entirely new attack surface, and the demonstrations here are grim.
The Gmail chain targets Claude Cowork, Anthropic's AI that connects to Gmail via a connector. Heyes chained Gmail's image-set() fallback — which could make an external request despite sanitization — to an indirect prompt injection. The setup: an attacker triggers a Slack token confirmation email to the victim's inbox. The victim asks Cowork to process their emails. The injected instructions in the attacker's email cause Cowork to retrieve the token and place it in an HTML draft. The victim views the draft. The token leaks.
Fastmail exposed a different variant targeting OpenAI's Atlas AI browser. CSS pseudo-elements and opacity adjustments made human-visible text harmless while the model read hidden instructions embedded beneath. When the user asked Atlas to translate the visible text, the hidden prompt caused it to open tabs and encode the victim's information.
This is not a sanitization bug. It's a fundamental property of how current AI email assistants consume content — they are designed to read and act on email text, which is exactly what an attacker wants them to do.
## Patch Status: Incomplete
Fastmail fixed two CSS mutation bugs. A Proton Mail proxy bypass stopped working when Heyes retested. Outlook label-jacking and Gmail's image-set() bypass were still functional when the research published on August 6. Public proof-of-concept code was available as of August 8.
The researcher's recommendations for providers: isolate HTML email in sandboxed iframes, restrict CSS significantly more aggressively, and tighten controls on custom attributes, select menus, and image requests. For consumers, the uncomfortable answer is that your webmail provider's sandboxing is the control, and you are not in a position to strengthen it yourself.
---
## HackWire Analysis
What Heyes has documented at Black Hat 2026 is not a novel category of attack so much as a proof that the category has never been closed — just periodically patched. CSS exfiltration techniques have been demonstrated against webmail since at least 2019, with research from security teams including Cure53 and others showing similar boundary-crossing risks. What's different now is the AI angle, and that shift deserves more attention than it's receiving.
Every AI email assistant currently in production assumes that the text it reads is inert content to be processed. That's a fundamental misalignment with how prompt injection works. When Cowork retrieves a Slack token because an attacker's email told it to, that's not Cowork behaving unexpectedly — it's Cowork behaving exactly as designed, just with adversarial input. The fix requires AI developers to treat injected instructions as a threat model distinct from sanitization, and most haven't gotten there yet.
The timing here also matters. AI email integration is accelerating. Microsoft Copilot in Outlook, Google's Gemini in Gmail, and a growing roster of third-party connectors are all expanding the attack surface that Heyes just showed is exploitable. The window between "this research was presented" and "attackers operationalize it against AI email tools" is shorter than providers seem to realize.
For enterprise defenders, the immediate action is to audit any AI email integrations against this attack class before assuming your sanitization controls are sufficient. They were designed for a different threat model. The realistic near-term posture for high-risk environments — executives, legal, finance — is to treat AI email connectors as unvetted until the relevant providers explicitly address prompt injection as a first-class threat rather than an edge case.
Webmail providers have been playing catch-up on CSS-based attacks for years. Adding AI intermediaries without solving the underlying boundary problem is compounding a debt that's now clearly callable.
— HackWire Editorial
---
## Related Coverage