CSS Emerges as a Stealthy Email Attack Vector, and Webmail Vendors Are Struggling to Respond
- PortSwigger researcher Gareth Heyes demonstrated that CSS and HTML alone — without JavaScript or attachments — are sufficient to build a working keylogger inside webmail platforms.
- Users have no ability to disable CSS in webmail clients, meaning the entire responsibility for protection rests with platform vendors through sanitisation and message isolation techniques.
- Some vendors dismissed Heyes' vulnerability disclosures before quietly patching the flaws later, raising transparency concerns about how email platforms handle security research.
- Heyes found hijacking bugs, advanced attack methods, and flaws in the webmail platforms of major, widely recognised vendors during his research.
- Every new CSS or HTML feature added by browser developers expands the potential attack surface, suggesting the risk will grow rather than diminish over time.
Cascading Style Sheets, the web technology long associated with fonts, colours, and page layouts, can now be weaponised to steal confidential user information from webmail platforms without any JavaScript or malicious attachments involved. That warning comes from Gareth Heyes, a web security researcher at PortSwigger, who presented his findings at Black Hat USA in Las Vegas. "CSS was on the back burner and largely ignored," Heyes said. "CSS and HTML alone — no JavaScript, no attachments — are enough to build a working keylogger."
Heyes described CSS as having grown so feature-rich it now resembles a programming language. While HTML provides the structure of a web page, CSS governs its visual presentation — text, colours, images, and tags. That breadth of control, Heyes argues, gives threat actors a surface to work with that most defenders have yet to treat seriously. "It's almost like a programming language now," he said.
The practical threat is compounded by a fundamental limitation facing ordinary users: they cannot switch CSS off. When a user receives an email with malicious CSS display features through a webmail client, they have no recourse at the individual level unless they happen to possess working knowledge of HTML and CSS. The burden of protection falls squarely on platform vendors. "From a webmail perspective, you can basically isolate the messages using a technology so that it can't interfere with the rest of the page," Heyes explained. "Webmail can also produce a more effective sanitisation of the CSS in order to prevent it from leaking out of the page, breaking out of the trust boundaries of the message."
Why this matters extends well beyond the technical. For years, email security investment has concentrated on known vectors — suspicious attachments, malicious JavaScript, and phishing links. CSS-based attacks sidestep all of those guardrails entirely. This points to a structural gap in how the industry defines the email threat landscape: if defences are calibrated around execution-based attacks, style-sheet-driven exfiltration remains essentially invisible to them. The practical effect for organisations relying on webmail platforms is that they may be exposed through a channel their security tooling was never designed to monitor.
Heyes' research journey also surfaces a troubling pattern in vendor behaviour. Some platforms responded to his disclosures swiftly and transparently. Others dismissed his findings outright, only to quietly implement fixes later without any public acknowledgement. This follows a broader pattern in vulnerability disclosure, where the absence of formal credit or communication leaves researchers — and ultimately users — without visibility into whether a risk has genuinely been addressed.
Looking ahead, Heyes has urged webmail vendors to correctly filter and sanitise user displays and recommended that security teams deploy an image proxy as a protective layer. He said his research uncovered hijacking bugs, various advanced attack methods, and flaws in the webmail platforms of well-known vendors. Browser developers also carry some responsibility, he noted, because the attack surface grows in step with every new CSS or HTML feature added. "What the browsers are doing all the time is adding new features to CSS, to HTML," he said. "But the problem is, as you add those features, the attack surface grows."