Gareth Heyes of PortSwigger titled the talk like a dare: "CSS: the bomb inside your inbox." At Black Hat USA 2026 he walked through how HTML and CSS in email, with no JavaScript, can break the trust boundary people still assume when they open a message in a browser tab. Outlook, Gmail, Yahoo, Fastmail, and AOL show up among the targets discussed in the research and in the secondary coverage from Dark Reading, The Hacker News, and PortSwigger's own blog. The demos are ugly in a quiet way. You think you are typing into your provider. You are typing into a layout the message painted on top of the chrome you trust. I kept waiting for the JavaScript twist. There was not one. That was the point.
Webmail without JavaScript still has a UI
Security training spent a decade telling people to fear attachments and links. Styled HTML in the message body got a shrug, because "email does not run scripts." Heyes's point is that scripts were never the only way to lie. Cascading styles can reposition, cover, and relabel. Labels and form-like structures can capture keystrokes into fields that look like a password box. Clipboard paste can be coaxed into the wrong place when a user thinks they are filling a legitimate challenge.
Outlook's web surface drew particular attention in the spoofed login and keylogger-style CSS plus labels path. I am deliberately not reproducing payloads. PortSwigger published research materials and GitHub proof-of-concept repos for people who need to reproduce in a lab. Readers here need the threat model: a rendered message can impersonate provider UI elements that sit in the same visual field as the real account.
Gmail, Yahoo, Fastmail, and AOL appear in the paper's target set with different constraints. Each webmail client sanitizes differently. Each still allows enough CSS or HTML for layout tricks that a careful attacker can chain. Vendor response after Black Hat has been mixed in the reporting I have seen - some acknowledgments and hardening talk, some "we already block the worst cases" language that does not match the talk's demos. Mixed is normal in the week after a conference. Mixed is also not the same as fixed.
Clipboard paste token theft is the detail that will haunt anyone who pastes TOTP codes or recovery strings into web forms. If the message can present a convincing paste target, user habit does the rest. That is not a crypto break. It is UI fraud with better typesetting.
Part of why this lands is the browser chrome problem. Users learn to trust the lock icon and the real microsoft.com or accounts.google.com URL. Webmail folds attacker-controlled HTML into a page that already earned that trust. The address bar stays honest while the pixels lie. Phishing training that only teaches domain reading misses the pane.
Mobile webmail and desktop dense layouts change which overlays work, which is why the research reads like a catalog rather than a single universal exploit. Attackers only need one reliable path per popular client. Defenders need to assume marketers will keep demanding the CSS features that make those paths possible.
AI mail readers make the same inbox worse
Heyes and the coverage also sketch a path that did not exist when CSS email tricks were a curiosity for phishing kits: AI tools that read mail on your behalf. Cowork-plus-Gmail style assistants that summarize or act on messages create a prompt injection surface. A message is no longer only pixels for a human. It is text and markup for a model that may follow instructions embedded in the body.
I keep those as related failures rather than one bug. CSS spoofing attacks the human eye and the browser layout. Prompt injection attacks the automated reader. Same inbox, different parser. If your company is rolling out an assistant with mailbox scope, Black Hat week is a bad time to assume HTML email is inert content.
The research does not claim every provider is equally broken on every trick on every day. Rendering engines change. Sanitizers tighten after talks like this, then loosen when a marketing template needs another animation. The durable lesson is that "no JavaScript in email" was never a complete security boundary. It was a comfort phrase.
There is a boring enterprise angle too. Secure email gateways spend heavily on URL rewriting and attachment sandboxes. Fewer of them treat CSS layout abuse as a first-class detection class. That mismatch is how a conference talk becomes a backlog item that loses to ransomware tabletop exercises until someone on the board gets phished through a fake password box in Outlook on the web.
What to change before the next phishing quarter
If you run security awareness, update the screenshots. People still look for bad domains in the from-line and ignore whether the message body is painting a fake password field over the thread. Tell them webmail can lie visually inside the pane. Tell them to type passwords only on a fresh navigation to the provider, not into a box that appeared after an email opened.
If you build or procure webmail, ask for a written stance on CSS repositioning, overlay, and label-based capture. Ask what changed after the PortSwigger disclosure. If the answer is only "we do not allow JavaScript," you got a slogan.
If you are evaluating AI inbox tools, demand isolation rules for untrusted HTML and a clear policy on whether message bodies can trigger tool calls. Cowork-class products that skim Gmail inherit every hostile newsletter on earth.
I walked out of the secondary write-ups annoyed at how old the ingredients are. CSS in email is ancient. Password fields in odd places are ancient. Black Hat still filled a room because the industry kept shipping richer HTML for newsletters while pretending the render surface was not an application. Heyes brought receipts. The providers now get to decide whether those receipts become patches or shrug emoji in a bug tracker.
My interim advice to friends who refuse to leave webmail is unglamorous. Prefer passkeys. Prefer typing the provider hostname yourself when something smells like a reauth prompt inside a message. Prefer a password manager that will not autofill into a weird field. None of that fixes the vendors. All of it shrinks how often a CSS costume gets a real secret.
How long the hangover lasts
Conference demos age into patch notes at uneven speed. Some providers will ship tight CSS allowlists within weeks because brand risk hurts. Others will argue edge cases and leave enough styling for newsletters that a patient attacker can still find a costume. Dark Reading and The Hacker News coverage already framed the mixed vendor mood. Expect that mood to persist past the news cycle.
Enterprise mail admins have a parallel homework set. Harden the clients you control. Push for plaintext or strongly constrained HTML in high-risk workflows. Force reauthentication flows into dedicated apps or hardware keys where you can. None of that is glamorous. All of it beats explaining to a CFO why the password was typed into a newsletter.
I keep a short list of research I revisit when inbox trust feels settled. Heyes just added another entry. CSS remains a presentation language people underestimate because it does not look like malware. Underestimate it again and Black Hat will book the sequel.
- Privacy
