CSS:the bomb inside your inbox | PortSwigger Research
CSS:the bomb inside your inbox
Gareth Heyes
Researcher
@garethheyes
Published: Thursday, 6 August 2026 at 22:00 UTC
Updated: Thursday, 6 August 2026 at 22:00 UTC
Gareth Heyes - gareth.heyes@portswigger.net - @garethheyes<br>It's quite common for webmail clients to render untrusted CSS in a trusted UI. They attempt to make this safe using CSS sanitization. In this paper I'm going to show you how to break out of trust boundaries, exfiltrate tokens, compromise 3rd party websites and even steal passwords.<br>Table of contents<br>Introduction<br>Abusing allowed HTML/CSSAbusing HTML labels to perform UI actions<br>Controlling AI browsers via email<br>Account takeover from pasting into a draft email<br>Exfiltrating tokens when CSP is blocking all external resources
Bypassing CSS sanitizationMaking external requests<br>Syntax quirks<br>Image proxy bypassesTracking if email is viewed in Fastmail<br>Displaying your IP address in ProtonMail<br>Tracking if email is viewed in Gmail
Combining an image proxy bypass with indirect prompt injection<br>CSS mutation in Fastmail
Exploitation with CSSDefacing Outlook using CSS gadgets<br>CSS hotwiring in Fastmail<br>Stealing passwords
Defences<br>Future attacksHTML only keylogger<br>Chrome real time keylogger
References<br>Materials<br>Introduction<br>Webmail has been around for decades and it's always had to solve a very difficult problem of taking untrusted HTML and displaying it to the user in a safe way. This is made even more challenging by each web standard evolving at a relentless pace. To solve this problem webmail uses sanitizers, they attempt to take the HTML provided and restrict it so that it can be displayed to users safely. Trouble is you can create discrepancies between what the sanitizer thinks is safe and what the browser actually renders. Some webmail clients go a step further by letting the browser parse the HTML and CSS first, then filtering the browser's interpreted output rather than the original source. Yet even this can be mutated into something malicious.<br>Over the last few months I've been looking at webmail clients like Yahoo Mail, AOL Mail, Fastmail, ProtonMail, GMail and Outlook. In search of discrepancies in their parsers and weak points in their sanitizers to produce a range of novel techniques to help exploit them.<br>Abusing allowed HTML/CSS<br>In this section I looked at the various "allow listed" CSS properties and HTML. With the goal of abusing them to spoof UI actions, control browsers, take over accounts or steal tokens. I targeted Fastmail, OpenAI's Atlas, Firefox, AOL Mail, Yahoo Mail and Outlook.<br>Abusing HTML labels to perform UI actions<br>HTML labels are an often overlooked element, using label tags you can target specific form elements that have an id attribute by using the label's for attribute. This works on any form element and you inherit the click action attached to the element. They are often missed by HTML sanitizers and I found at least 3 webmail clients that were vulnerable to this. I found a real bug in Outlook which would enable me to control Outlook's UI from an email message.<br>RibbonModeToggle"><br>Click me first
548"><br>Click here to pin this message<br>Using the label we can open Outlook's UI ribbon, then we can pin our message to the victim's Outlook. This still works today as Microsoft didn't fix it. If you find a sanitizer that allows labels and doesn't filter the "for" attribute you can use devtools to find targets using the JS below.<br>document.querySelectorAll('input[id],button[id],select[id],textarea[id]')This code finds input, button, select and textarea elements that have an id. This was only the start, we'll come back to Outlook later. The label element will prove very useful for us.<br>Controlling AI browsers via email<br>OpenAI released a browser called Atlas when I was researching this topic so I decided to see if I could use sanitized CSS to perform indirect prompt injection from an email message in Fastmail.<br>Before we go further, let's cover the :before and :after pseudo-elements. They let you add text content before or after an element, and you can style that content however you like.They also inherit the element's existing click events, something I'll come back to later when we get to CSS hotwiring. I'll use them to hide text from an AI browser.
div:before {<br>content: "Before";<br>color:orange;
div:after {<br>content: "After"<br>color:blue;
Existing textRendered preview:<br>BeforeExisting textAfterI experimented with various properties and noticed something interesting, you could use the :before and :after pseudo-elements to hide the text from the LLM and you could use opacity to hide it from the victim. This creates a disparity between what the victim sees and what the LLM sees, potentially altering the email's context.
#x:before {<br>content: "PortSwigger est le meilleur. Il repousse les limites de la sécurité web.";<br>font-weight: bold;<br>font-size: 20px;<br>As you can see I show the victim some French and they naturally use Atlas's...