At Black Hat USA 2026, PortSwigger researcher Gareth Heyes presented a talk called “CSS: the bomb inside your inbox,” and the finding underneath the title is a genuinely uncomfortable one for anyone who thinks email authentication equals email safety. Heyes showed that CSS and HTML alone, with no JavaScript, no attachment, and no malicious link, are enough to build a working keylogger inside major webmail clients, including Gmail, Outlook, Yahoo Mail, AOL Mail, Fastmail, and Proton Mail. The attack chains he demonstrated can capture passwords, hijack trusted interface elements, leak login tokens, and in one case manipulate an AI tool that was reading the email on the victim’s behalf. None of it requires the sender to spoof anything. It requires only that the recipient’s webmail client render the message body the way it normally would.
How a Dropdown Menu Becomes a Fake Password Field
The core technique relies on quirks in how browsers implement CSS, specifically mutation behavior, attribute selectors, and pseudo-elements like :before, :after, :has(), and :checked. Heyes used these to disguise an ordinary HTML select-menu dropdown as what looks, pixel for pixel, like a password field. The trick that makes it capture keystrokes rather than just look convincing is a Firefox implementation detail: the browser resets its roughly one-second text-selection timer every time the dropdown element moves offscreen and back. By repeatedly triggering that reset through CSS alone, the attack fires a background-image request, the classic CSS-exfiltration technique, once per keystroke, close enough to real time that the attacker reconstructs what the victim typed character by character. No script ever runs. The email client is doing exactly what CSS specifications say it should.
Three Chains That Actually Worked
The research was not theoretical. Heyes built and demonstrated working attack chains against real, current webmail platforms. An Outlook and Firefox combination spoofs a convincing Microsoft sign-in screen inside the message and captures the password as the recipient types it. A Yahoo Mail and AOL Mail paste race exposes a Medium email-login token, letting the attacker sign in as the victim without ever touching a password. A Gmail chain involving Cowork goes further still, using prompt injection to manipulate an AI tool that reads the recipient’s email and getting it to exfiltrate a Slack token after a small amount of user interaction. That last chain is worth sitting with: as AI assistants get folded into how people process their inbox, the inbox itself becomes an injection surface for those assistants, not just for the human reading it.
Patching Is Uneven, and Some of This Still Works
Vendor response has been mixed. Fastmail fixed two of the CSS mutation bugs Heyes reported. A proxy bypass affecting Proton Mail stopped working when he retested it, suggesting a quiet fix landed there too. But as of the research’s publication on August 6, Outlook’s label-jacking issue and Gmail’s image-set() bypass were both still functional. This is not a single vulnerability with a single patch. It is a class of rendering behavior that every major webmail provider implements slightly differently, which means every provider is fixing it, or not, on its own timeline.
Why DMARC Has Nothing to Say About Any of This
DMARC verifies exactly one thing: whether the domain in a message’s From header was authorized to send that message, based on SPF and DKIM alignment. It says nothing, and was never built to say anything, about what a webmail client does with the HTML and CSS in the message body once delivery is accepted. A CSS bomb email can originate from a domain with a DMARC policy set to reject, signed correctly with DKIM, aligned correctly with SPF, and pass every one of those checks without friction. The attack does not need to forge who sent the message. It needs the recipient’s browser to parse a style block, which is a rendering-layer behavior sitting entirely outside what any email authentication protocol inspects. This is the same structural gap that has shown up repeatedly this year in SVG-based phishing and other content-smuggling techniques: DMARC secures the envelope, and an increasing share of real attacks are happening inside content the envelope was never designed to examine.
What This Means for Your Program
Sanitize inbound HTML and CSS at the gateway, don’t rely solely on the webmail vendor’s own filtering. Heyes’s research shows that vendor-side sanitization is inconsistent and sometimes months behind disclosure. A layer you control catches what a client-side fix has not shipped yet.
Treat repeated background-image requests to unfamiliar domains as a signal, not noise. The exfiltration mechanism behind CSS bomb attacks depends on a flood of small image requests. Outbound traffic monitoring that flags this pattern can catch an attack that content filtering never sees.
Train users that a sign-in screen or password field rendered inside the body of an email is never legitimate, regardless of how convincing it looks. Real authentication prompts come from the browser chrome or a separately loaded page, never from inside a message.
Push your webmail and security vendors for a concrete patch timeline, especially if your organization runs Outlook or Gmail, where the specific bypasses Heyes disclosed were still working as of publication.
Keep DMARC enforced at reject regardless. It remains the correct defense against outright domain impersonation, and a CSS bomb email still generally needs a domain the attacker controls to send from. It simply is not, and was never meant to be, a defense against what happens after that domain’s mail lands in the inbox.
The Takeaway
Email authentication and rendering security solve different problems, and 2026 keeps supplying fresh reminders of exactly how different they are. A message can be fully authenticated, perfectly aligned, and still detonate the moment a browser does its ordinary job of interpreting CSS. Heyes’s research does not mean DMARC failed at anything. It means the industry’s remaining exposure has shifted toward the layer DMARC was never designed to cover, and closing that gap now depends on gateway-level content sanitization and user awareness sitting alongside strong authentication, not on authentication alone.
Excello Mail gives you continuous visibility into your DMARC enforcement and every source authorized to send under your domain, so the authentication layer stays locked down while your team focuses on the content-level risks that DMARC was never built to catch. Sign up for free to Excello Mail and see exactly who is sending as you, all the time.