How an email with no script at all can steal your password

PortSwigger Research published a study on 6 August of how style rules in an email can break out of the message itself and reach into the webmail client's own interface. The work is by Gareth Heyes, and was presented at Black Hat USA 2026 under the title "CSS: the bomb inside your inbox". The study shows attacks against Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail and AOL Mail. The outcomes range from theft of passwords and login tokens to disclosure of the recipient's IP address. No CVE numbers are stated, and the researchers report no known malicious exploitation.

What happens technically

A webmail client displays foreign HTML inside its own page, and must therefore sanitise the content before inserting it. All the attacks build on the same condition: the sanitiser and the browser disagree about what the same text means. Where the sanitiser reads a string as harmless, the browser reads it as a valid style rule, and the rule applies to the whole page rather than only inside the message. Heyes describes several routes in, among them rewriting style rules through the browser's own style object, bypassing image proxies using a backslash, and reusing style properties that the application's own JavaScript adds to elements.

The outcomes vary with client and browser. In Outlook, hijacking of label elements is combined with such style properties so that an element outside the message can be steered, and the researchers show a fake sign-in overlay that captures the password as it is typed in Firefox. In Yahoo Mail and AOL Mail, a brief window during pasting in Firefox is exploited, where pasted HTML still carries active style rules, and a twelve-character token can be extracted. In Gmail, a fallback value in the image-set function triggers an external request that sanitisation should have stopped, and the researchers chain this together with indirect prompt injection against an AI assistant connected to the mailbox. That chain ends with a Slack token being placed in a draft. Fastmail fixed two of the bugs while the work was under way, and Proton Mail closed the bypass that revealed the recipient's IP address. According to the researchers, both the label hijacking in Outlook and the image-set bypass in Gmail were still open when the study was published.

What this means for you if you are responsible for email

As we see it, this moves a line many believed had been drawn long ago. HTML in email has been treated as manageable risk because scripts are stripped, and because images can be blocked. The study shows that style rules alone suffice to build a fake sign-in field and to leak content out. The protection therefore sits with the provider of the webmail you use, and not with the person reading the email.

The part involving AI deserves your attention most of all right now. The chain Heyes shows in Gmail begins in an email and ends in a Slack token, because the assistant reads the mailbox on the user's behalf and acts on what it reads. If you let an assistant reach several services at once, every incoming message becomes a possible instruction. That is a risk you control yourself, through which connections the assistant is allowed to hold.

Berigo recommends

• Treat the connection between an AI assistant and the mailbox as an access decision, and give the assistant as few services at once as possible.
• Enable image proxying and blocking of external images where the webmail client offers it.
• Remind users that a sign-in field appearing inside an email must never be filled in. Go to the service in a separate tab instead.
• Follow the provider's security advisories for the webmail client, since the fixes here arrive server-side and not as something the user can install.
• Include this attack pattern in training, so that an interface behaving oddly gets reported rather than merely clicked away.