Skip to content
Beveiligingsnieuws

CSS Attacks in Webmail: How Defenses Can Fail

CSS-aanvallen op webmail

Security researchers have found new ways for CSS attacks webmail to undermine protections. The key idea is simple but serious: HTML and CSS that should stay inside an email can sometimes influence the trusted webmail interface around it. That creates opportunities to steal passwords and tokens, hijack trusted actions, and even manipulate AI tools that read mail content.

The findings were presented by PortSwigger researcher Gareth Heyes at Black Hat USA 2026. The report includes proof-of-concept research based on real-world webmail systems, along with mitigation guidance for providers and defenders. Importantly, the paper describes proof-of-concept work and does not claim that full malicious exploitation was observed.

Why CSS inside emails can become dangerous

Email is normally treated as untrusted content. Webmail clients sanitize message bodies and then render them inside a safe boundary. According to the research, attackers can exploit situations where the rendered output diverges from what a sanitizer expects.

Two main paths show up across the described attack chains. First, attackers can abuse HTML and CSS that the webmail interface already allows in messages. Second, attackers can create a mismatch between what sanitization permits and what the browser or the application ultimately creates—effectively crossing the boundary between the untrusted message and the trusted UI.

What attackers may try to steal

The report outlines multiple outcomes that go beyond visual spoofing. Across chains involving Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail, the research describes ways to:

  • Capture passwords typed into spoofed login experiences.
  • Take over third-party accounts by stealing session material or confirmation tokens.
  • Leak tokens tied to email login flows.
  • Hijack trusted UI actions that webmail normally handles safely.
  • Manipulate connected AI tools that process messages, causing them to reveal hidden instructions or act on embedded prompts.

Outlook and Firefox: spoofed sign-in and real-time capture

One of the Outlook chains described by Heyes targets a scenario involving a Microsoft sign-in screen. The research states that the chain can spoof a sign-in interface and capture the password a recipient types.

Technically, the sequence combines multiple pieces: allowed label elements can trigger controls outside the email content, and application-side JavaScript can turn sanitized custom attributes into new DOM nodes that carry CSS outside the sanitizer’s allow list. From there, a media-query parsing trick can be used to obtain arbitrary CSS.

The chain also disguises a selection control as a password field. In the Firefox part of the demonstrated setup, the timing behavior matters: when the select element moves offscreen, Firefox resets an approximately one-second option-selection timer, which makes the capture work in real time.

Yahoo Mail and AOL Mail: token exposure via paste and race

The research also describes a different route affecting Yahoo Mail and AOL Mail. In Firefox, pasted HTML can briefly retain active CSS before sanitization fully applies.

In the Medium demonstration cited in the report, the attacker initiates an email-login flow. Then the victim copies attacker-supplied CSS and pastes it into a Yahoo or AOL draft. The resulting requests are said to reveal enough of a login token—described as a 12-character value—for an attacker’s server to reconstruct it and sign in as the victim.

In other words, the attack leverages what the user does during a normal workflow: copying content and pasting it into a webmail compose interface, where CSS influence can still leak sensitive request details.

Gmail and connected services: exfiltrating Slack tokens

For Gmail-related chains, the report describes an approach aimed at exfiltrating a Slack token after prompt injection and user interaction. The text indicates a “Gmail/Cowork” style scenario where CSS behavior and user-driven steps combine to move sensitive confirmation material out of intended boundaries.

As summarized in the research narrative, a connected workflow can result in a token landing inside an HTML draft. When the victim views that draft, the leak mechanism can reveal the token to the attacker.

Fastmail and AI/browser workflows

Fastmail appears in the report with multiple demonstrations. One focuses on what the researcher calls “CSS hotwiring,” described as a way to redirect clicks into unintended, multi-step UI actions. Another demonstration references a Fastmail image-proxy bypass, relying on an allow-listed user.fm domain to reveal when an email is viewed.

There is also an AI-centric experiment involving OpenAI’s Atlas AI browser. The research says CSS pseudo-elements and opacity can make content appear harmless to a human while instructions remain readable to the model. In the demonstrated setup, when a user asked Atlas to translate visible text, hidden prompts reportedly caused the browser to open tabs and encode the victim’s name in URL fragments.

OpenAI is reportedly deprecating Atlas, with a schedule to stop working on August 9, 2026, according to the report.

Proton Mail: an IP-address privacy angle

Beyond credential and token theft, the report includes a Proton Mail vector that can expose a recipient’s IP address. Proton’s documentation, as quoted in the research summary, states that the service is designed to hide a user’s personal IP address and the exact email-open time.

The presence of a described PoC suggests that CSS or rendering behavior can still create network-visible signals under certain conditions, even when tracker protection is intended to reduce exposure.

How researchers demonstrated leaks when external requests are blocked

The report also introduces a click-based exfiltration technique for environments where a Content Security Policy (CSP) blocks external resources. In these cases, the approach uses CSS to infer values rendered as text in the email.

For example, the summary describes a numeric token rendered within the message. With style injection, CSS can be used to determine which digits appear and how often, while hiding non-matching links. A matching link is left available across the page. Then a victim click sends the digits and their frequency to the attacker’s server.

This is notable because it does not rely on direct external loading. Instead, it turns user interaction into a channel for leaking information.

Reported fixes and which issues may still matter

The report states that Fastmail fixed two CSS mutation bugs, and that a Proton Mail proxy bypass stopped working when Heyes retested it. It also notes that when research was published on August 6, Outlook label-jacking and Gmail’s image-set() bypass still worked at that time.

At the same time, the paper does not say whether the full Outlook password-capture chain was fixed. That uncertainty matters for defenders: some chains may require multiple changes across parsing, sanitization, and rendering to fully close.

Defensive guidance for webmail providers

The research recommends a defense-in-depth approach. The first and most important step is isolating HTML email in sandboxed iframes. That reduces the chance that injected content can influence the surrounding application or trusted UI.

Next, the report emphasizes strict validation for CSS and related features. The defensive measures described include:

  • Tightly restricting CSS and validating allowed characters or structures.
  • Checking for dangerous CSS “gadgets” before permitting custom attributes.
  • Blocking select menus and other high-risk UI elements.
  • Preventing attacker-controlled image requests and restricting allowed domains, including any allow-listed third-party sources.

Takeaway: treat “style-only” content as active input

The central lesson from this work is that CSS attacks webmail can turn style information into a control or exfiltration mechanism. Even when the email body is sanitized, subtle differences between what is allowed, what is created in the DOM, and how the webmail interface interprets it can create pathways to leak sensitive data.

If you run a webmail provider or maintain email rendering components, the recommended mitigations point toward stronger isolation and stricter allow-lists. If you are a user, the most practical advice remains to be cautious with copied content and unexpected login or confirmation flows that ask you to paste material into drafts.

Bottom line: the research shows that protecting webmail is not only about blocking scripts. CSS and HTML features—especially when combined with UI behavior—can still threaten password entry, token security, privacy, and even connected AI workflows.

Source: https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html