Your Email's Design Layer Can Steal Your Password. No Suspicious Attachment Required.
Security researcher Gareth Heyes found that CSS, the code responsible for how emails look on screen, can be turned into a data-theft tool inside popular webmail services. No malicious files. No links to click.
Key points
- Gareth Heyes, a web security researcher at PortSwigger, demonstrated at Black Hat USA 2026 that CSS alone can be used to build a keylogger inside email.
- CSS-based attacks require no malicious attachments and no JavaScript, the programming language browsers use to run interactive features.
- Heyes found real vulnerabilities in major webmail platforms; some vendors fixed the issues quietly without giving him credit.
- Users cannot turn CSS off, so the fix must come from the email providers themselves.
- Webmail companies can limit the damage by isolating messages and filtering their CSS more aggressively.
Everyone has been warned about dodgy email attachments and suspicious links. That warning is good. It is also incomplete.
At Black Hat USA 2026 in Las Vegas, PortSwigger researcher Gareth Heyes showed the security community something most defenders hadn't thought to watch: CSS, short for Cascading Style Sheets, the code that controls how a webpage or email looks on your screen, the colours, fonts, layout. Used maliciously, it can silently steal what you type.
"CSS and HTML alone, no JavaScript, no attachments, are enough to build a working keylogger," Heyes said, referring to software that records every key a person presses and captures passwords or other sensitive text.
How does an email steal your keystrokes without any attachment?
Modern CSS has grown far more capable than most people realise. It began as a simple decoration tool and has quietly gained features that behave like a programming language.
Heyes first noticed the potential while experimenting with personal projects. He found that CSS animations and attribute selectors, rules that watch for changes on a page, can be strung together to leak information character by character out of an email client. The moment the email renders on screen, the mechanism can run. No download, no interaction from the reader.
"It's almost like a programming language now," he told the Black Hat audience. "CSS was on the back burner and largely ignored."
The Zimbra stored cross-site scripting bug we reported on 11 July showed how little a rigged email needs to do damage the moment it opens. CSS-based attacks push that further: there is no script to block.
| Attack ingredient | Traditional email attack | CSS-based attack |
|---|---|---|
| Malicious attachment | Required | Not needed |
| JavaScript | Often required | Not needed |
| User must click something | Usually | No |
| Blocked by attachment scanners | Often | No |
| Visible to current email filters | Mostly | Largely no |
Should ordinary email users be worried?
Yes, but the fix isn't yours to make. Users have no option to disable CSS inside webmail services like Gmail or Outlook on the web. Protection has to come from the platform.
Heyes says webmail providers can isolate each message so its styling code cannot reach outside the message box and interact with the rest of the page. They can also scrub, or "sanitise", the CSS before it ever renders, stripping out the dangerous parts. Neither step is technically exotic, and both are currently inconsistent across major providers.
His research uncovered real hijacking bugs and advanced attack methods inside vendors' platforms. Some companies responded quickly. Others dismissed the reports, then quietly pushed patches later with no public credit to Heyes.
What should people who use webmail do right now?
Two things. Keep your browser and webmail app updated, since providers who did fix these issues shipped the patches through normal updates. Watch for unexpected password-reset emails or account-activity alerts after opening unfamiliar messages, because those can signal something ran silently in the background.
The judgment worth making here is that this is less a novel attack class than a neglected one. Browsers keep adding CSS features; each addition expands the surface available to attackers. Vendors who aren't actively filtering for CSS-based abuse aren't keeping pace with changes in their own product. That gap is the real story.
