CSS email attacks: your inbox renders attacker code

An email with no JavaScript, no attachment, and no link you have to click can log your keystrokes inside Outlook. That is the headline result from PortSwigger's Gareth Heyes, published August 6 as CSS: the bomb inside your inbox and presented at Black Hat USA 2026. CSS email attacks are not a novelty demo anymore, and the part that should worry you most is what they do to the AI assistant you pointed at your mailbox.

What actually happened

Heyes went through Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail looking for content that escapes the message body and reaches the surrounding interface. He found it in all of them.

The keylogger runs inside Outlook's sanitized HTML using <select> elements paired with CSS pseudo-classes — in Firefox it captures in real time. A separate Outlook bug abuses the <label> element's for attribute to reach controls outside the message, letting an attacker pin their own message into the victim's mailbox UI. That one was still unfixed when the research went out.

Token theft works through CSS attribute selectors that fire background-image requests one character at a time. When a strict Content Security Policy blocks those requests, Heyes falls back to a font-height oracle — measuring how tall an element renders — to leak digits without any network call from the styled element. He used it to lift a Medium login token from a Yahoo/AOL paste race.

Three image proxies got bypassed: Fastmail via an escaped backslash in the URL, Proton Mail via comment injection, and Gmail via a CSS variable fallback. Fastmail fixed its mutation bugs and paid two $1,000 bounties. Proton patched quietly. Google's team rejected the Gmail proxy report on the grounds that user interaction was required, so Heyes weaponized it anyway and used it to exfiltrate a Slack token from a draft email an AI assistant had written.

Why CSS email attacks matter for your business

Here is the part that generalizes past webmail. Using ::before and ::after with opacity, Heyes built messages that render one way to a human and a different way to a language model reading the same DOM. He then drove OpenAI's Atlas browser into taking actions through that gap.

Every "connect your inbox and let the agent triage it" workflow inherits this. Your model does not read what you read. It reads markup, and markup is attacker-controlled the moment an outsider can email you. If that agent can also send mail, file tickets, or touch your CRM, an unopened message is now a command channel.

You cannot patch Outlook. You can control three things. First, keep the agent's read scope and write scope separate — an inbox-reading agent should not hold credentials that let it act on what it reads. Second, strip inbound HTML to plain text before it enters a model's context; you lose formatting and you delete the entire class of attack above. Third, put an approval gate on any agent action with an outside blast radius, and log what triggered it. None of that is exotic. It is the same untrusted-input discipline you would apply to a web form, applied to the channel you forgot was a form.

Sources: PortSwigger Research, The Hacker News.