New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens

New research into the security of HTML email demonstrates that Cascading Style Sheets can become considerably more dangerous than their traditional role of controlling colours, fonts and page layout would suggest. PortSwigger researcher Gareth Heyes identified a collection of techniques capable of abusing permitted HTML and CSS, exploiting differences between sanitizers and browser parsers, manipulating trusted webmail interfaces, exposing authentication tokens and creating highly convincing credential-stealing interfaces. The research examined Outlook, Gmail, Yahoo Mail, AOL Mail, Fastmail and Proton Mail and also demonstrated how malicious email content can influence AI systems connected to inboxes. The findings do not represent one universal vulnerability affecting every email provider, but collectively they reveal a broader architectural weakness: many webmail applications render attacker-controlled message content inside or alongside highly privileged user interfaces and depend on increasingly complex sanitization rules to keep those two security domains separate. 

Webmail providers face an unusually difficult security problem because email is expected to support rich HTML formatting while every incoming message must simultaneously be treated as hostile. JavaScript is generally removed because allowing arbitrary scripts inside an email would obviously give attackers access to the surrounding application, but HTML and CSS cannot simply be discarded without significantly reducing modern email functionality. Providers therefore sanitize incoming messages, permitting a carefully selected subset of elements, properties and attributes that should theoretically allow formatting without allowing the message to interfere with the application itself. Heyes’ research demonstrates that this security model becomes fragile when browser behaviour evolves faster than those sanitization rules or when seemingly harmless HTML and CSS features can be combined in unexpected ways.

The fundamental problem is not necessarily that a sanitizer completely fails to inspect malicious content. In several of the demonstrated attacks, the sanitizer performs exactly the type of transformation its developers intended, but the browser later interprets the resulting markup differently. Another class of problems occurs when webmail deliberately permits individual features that appear safe when considered independently but become dangerous when combined with application JavaScript, browser behaviour or other CSS functionality. Security therefore depends not only on what HTML enters the page but also on what DOM structure eventually exists after browsers, frameworks and scripts have processed it.

One of the simplest demonstrations involved the HTML `label` element. Labels are normally used to associate descriptive text with form controls, and clicking a label can activate the element identified through its `for` attribute. Heyes found that Outlook allowed attacker-controlled labels inside email content and that these labels could reference controls belonging to Outlook itself rather than remaining restricted to the message. A malicious email could consequently trigger elements in Outlook's trusted interface, including opening UI components or pinning the attacker’s message. This technique remained functional when the research was published, illustrating how an ordinary accessibility feature can become a cross-boundary control mechanism when message content shares the same DOM environment as the surrounding application.

The significance extends beyond the specific Outlook actions demonstrated. A sanitized email should behave like untrusted content contained within its own security boundary, yet an HTML label capable of targeting controls outside that boundary effectively allows the message to operate parts of the application interface. The attacker does not need JavaScript because the browser already implements the click behaviour. Security systems therefore need to evaluate semantic interactions between permitted elements and the host application rather than merely checking whether an individual HTML tag is considered dangerous.

The Outlook research became considerably more serious when multiple techniques were combined into a credential-phishing chain. Application JavaScript could transform sanitized custom attributes into additional DOM elements, providing access to CSS behaviour that the sanitizer itself had attempted to restrict. A CSS media-query parsing technique then allowed the attacker to obtain much broader styling control over the page. Using that capability, the researcher demonstrated how a standard HTML `select` element could be visually transformed into something resembling a Microsoft password-entry field.

This approach is especially dangerous because the fraudulent authentication interface exists inside the genuine Outlook web application rather than on an unrelated phishing domain. Users are commonly trained to examine website addresses before entering credentials, but a malicious interface rendered within the authentic webmail origin undermines that advice. The user may verify that the browser genuinely displays Microsoft's domain and still be looking at attacker-controlled content positioned over or styled to resemble the trusted interface.

The proof of concept used Firefox behaviour to capture the password through the disguised selection control. Browser behaviour surrounding option selection and movement of the control could be manipulated so that characters entered by the victim were reflected through attacker-observable interactions. The complete chain required a particular collection of conditions and does not mean arbitrary Outlook accounts can automatically be compromised simply by receiving an email. Nevertheless, it demonstrates that CSS and ordinary form behaviour can approach capabilities normally associated with executable scripting when the attacker can control enough of the surrounding document.

Yahoo Mail and AOL Mail exposed a different class of weakness involving content pasted into email drafts. When HTML containing CSS was copied to the clipboard and pasted into the message composer using Firefox, the CSS could remain active briefly before sanitization completed. This created a race condition during which attacker-controlled styling could interact with content elsewhere in the draft. Heyes used the behaviour to demonstrate theft of a Medium email-login token.

Medium's passwordless email-login mechanism generated a 12-character hexadecimal token inside a URL. The attacker could initiate a login attempt using the victim's email address and then convince the victim to copy attacker-supplied content and paste it into a Yahoo or AOL draft. CSS attribute selectors could examine portions of the login URL and generate network requests corresponding to matching token fragments. By carefully combining nested selectors and overlapping portions of the token, the attacker's server could reconstruct enough information to recover the full authentication value and log into the victim's Medium account.

The technique demonstrates why CSS exfiltration remains relevant even in environments where JavaScript execution is prevented. CSS selectors are designed to apply styles conditionally according to properties of elements. When those conditional styles can request external resources, each network request becomes a signalling mechanism. The browser effectively performs a test against secret content and communicates the result to the attacker simply by deciding whether to fetch a background image.

This concept has existed in security research for years, but modern CSS substantially increases what can be expressed without JavaScript. Attribute selectors, nesting, custom properties, animations, pseudo-elements, mathematical functions and font features can collectively form surprisingly sophisticated computational and information-disclosure primitives. Sanitization models that were created when CSS was primarily considered decorative therefore need continual reassessment as the language gains more expressive functionality.

Heyes also developed a technique for extracting information even when Content Security Policy prevents the email from making arbitrary external resource requests. The demonstration focused on numeric tokens rendered as text. CSS fonts, Unicode ranges and animation behaviour could determine which digits were present and how frequently each occurred. Rather than sending this information automatically through background network requests, the CSS manipulated links so that the link corresponding to the discovered combination occupied the visible page. When the victim clicked, the browser transmitted the inferred digits and their frequencies to the attacker.

This technique is important because Content Security Policy is frequently treated as a strong final barrier against CSS data exfiltration. CSP remains an essential web security control and can prevent many external requests, but the research shows that attackers may redirect information through user interactions already permitted by the application. The browser does not need to make a forbidden background connection when attacker-controlled styling can influence which legitimate clickable destination the victim ultimately activates.

Image handling created another series of weaknesses. Webmail providers commonly proxy remote images so the sender cannot directly observe the recipient's IP address or determine precisely when an email was opened. The mail service retrieves the image on behalf of the user and serves it through its own infrastructure, breaking the direct connection between the recipient's browser and the attacker-controlled server. CSS syntax, however, offers numerous methods of requesting images beyond a simple `background:url()` declaration.

Heyes catalogued alternatives involving `image-set()`, WebKit-specific image functions, masks, imports and unusual CSS parsing forms. These differences matter because a sanitizer that recognises only the most familiar URL syntax may allow another representation that eventually causes the browser to make the same external connection. CSS is unusually tolerant of whitespace, escaping and malformed-looking syntax, making blacklist-based validation particularly difficult.

The researcher demonstrated image-proxy bypasses affecting several platforms. A Fastmail technique used escaped characters within a URL to create a request that sanitizer logic interpreted differently from the browser, potentially allowing a sender to determine when an email had been viewed. A separate Proton Mail demonstration exposed the recipient's IP address despite the service's privacy mechanisms intended to prevent senders from learning a user's actual network address or precise email-open timing. The Proton technique reportedly stopped functioning when retested later, while other findings remained active when the research was published.

Gmail was affected through yet another CSS parsing discrepancy involving `image-set()`. The sanitizer could block familiar external-image syntax while a fallback representation still caused the browser to initiate a network request. By itself, this provides an information-leak mechanism, but the researchers demonstrated that it becomes substantially more concerning when email is consumed by an AI agent rather than directly by a person.

In the Gmail demonstration, the attacker triggered a Slack email containing an authentication token and introduced malicious instructions into another email. When the victim asked Anthropic's Claude Cowork to process the mailbox, the indirect prompt-injection instructions influenced the agent to retrieve the sensitive token and insert it into an HTML email draft. The CSS image-request bypass then caused information from that draft to be transmitted externally when the draft was viewed. The attack combines three security domains that organizations traditionally analyse separately: email sanitization, browser networking and AI prompt injection.

This combination provides an important warning as email platforms become connected to AI assistants. Historically, the main security concern was whether a malicious email could attack the human reading it or exploit the webmail application rendering it. An AI agent introduces another interpreter with its own permissions and decision-making process. Content invisible or innocuous to a human may contain instructions meaningful to the model, while CSS can deliberately create differences between what the human sees and what the AI system processes.

The Fastmail demonstration targeting OpenAI's Atlas AI browser illustrated this directly. CSS pseudo-elements could insert text that the AI model interpreted while opacity and layout techniques prevented the human user from seeing the same instructions. A victim could therefore believe they were asking an AI tool to translate or analyse harmless visible text while the model received a substantially different prompt containing attacker-controlled instructions. In the proof of concept, those hidden instructions caused the browser agent to open external tabs and encode information about the victim into URLs.

This creates a new form of presentation-layer security problem. Traditional phishing attacks attempt to make malicious content look trustworthy to the human. AI-connected applications introduce the opposite possibility: attackers can make content look harmless to the human while presenting malicious instructions to the machine. Security products therefore need to consider whether user-visible and machine-consumed representations of the same content differ materially.

The research also introduced a concept described as CSS hotwiring, where pseudo-elements and CSS positioning are used to redirect clicks intended for one interface element toward another action. Pseudo-elements such as `::before` and `::after` can inherit interaction behaviour associated with the element on which they are placed. By repositioning those generated elements across other portions of the interface, an attacker may cause a user to believe they are clicking one control while actually activating another.

This is conceptually similar to clickjacking, but instead of embedding a remote page inside an iframe, the malicious message uses styles already permitted within the webmail environment to rearrange interactive regions. If a sanitizer allows CSS powerful enough to move, resize or overlay elements, the email can begin influencing trusted interface behaviour without requiring conventional script execution.

The findings demonstrate why rendering email HTML directly inside the same document as the trusted webmail application creates structural risk. Sanitization attempts to transform inherently attacker-controlled markup into something sufficiently safe to coexist with authenticated controls, tokens and application state. Every new browser feature, parsing difference or CSS capability potentially changes the assumptions on which that sanitizer was built.

A stronger architectural approach is isolation. PortSwigger recommends placing untrusted email HTML inside sandboxed iframes so that the message exists within a distinct browsing context rather than sharing the webmail application's DOM. Proper sandboxing can prevent labels, selectors and other message-controlled elements from reaching outside their own document and interacting directly with trusted interface components.

Isolation reduces dependence on perfect sanitization. Sanitization remains valuable because content inside the iframe should still be restricted, but a failure does not automatically grant access to the surrounding application. This follows a familiar security principle: untrusted content should be separated by an enforceable security boundary rather than allowed into a privileged environment after attempting to remove every dangerous capability.

CSS validation itself should favour restrictive allowlists rather than extensive deny lists. The language supports numerous alternative syntaxes for URLs, escaped characters, browser-specific properties and emerging functions. A sanitizer attempting to enumerate every dangerous construction is likely to fall behind browser evolution. Allowing only the limited properties and characters genuinely required for email formatting provides a more manageable security model.

Webmail providers should also reconsider whether advanced CSS features are necessary inside ordinary email. Select menus, custom attributes, complex selectors, animations, pseudo-elements and dynamically requested images provide limited value for most legitimate messages while significantly increasing attack capability. Email does not need the expressive power of a modern web application simply because both are rendered by a browser.

Custom attributes deserve particular scrutiny because application JavaScript may later consume them and generate new DOM structures that were never inspected by the original sanitizer. Sanitization cannot safely consider only static HTML when trusted application scripts subsequently transform those attributes into new elements or styling rules. Security review must encompass the complete lifecycle from message parsing through final DOM mutation.

Image requests should similarly be constrained at a lower architectural level rather than depending entirely on identifying every CSS property capable of initiating one. If a message should not connect directly to arbitrary external servers, the platform should enforce that policy across all browser resource-loading mechanisms. A new CSS function should not silently reopen a network path simply because the sanitizer was written before that function existed.

Webmail providers also need continuous differential testing across browsers. Chrome, Firefox and Safari may parse malformed or unusual HTML and CSS differently, as demonstrated by the clipboard behaviour in Yahoo and AOL Mail. Content that is safe under one browser may acquire unexpected meaning under another. Sanitizers therefore need to be tested against the actual browser parsing engines used by customers rather than validated against one idealized interpretation of the standards.

Enterprise defenders have fewer direct controls because most of these weaknesses must ultimately be corrected by webmail providers. Nevertheless, organizations can reduce exposure through browser management, rapid updates and restricting use of unsupported or unusually permissive webmail interfaces. Security teams should pay attention to vendor advisories involving HTML sanitization even when the vulnerability description mentions only CSS, because the potential consequences can include credential theft and account compromise rather than cosmetic manipulation.

Remote image policies remain useful, particularly for high-risk users. Blocking automatic external content reduces many tracking and CSS-based signalling opportunities, although the research shows it does not solve every attack. Users should also remain cautious about copying formatted content from untrusted websites and pasting it directly into email composers, because clipboard HTML can contain significantly more structure than the visible text suggests.

For organizations operating self-hosted webmail platforms, content isolation and sanitizer maintenance deserve the same attention as server-side vulnerabilities. Recent campaigns against Zimbra and other webmail products have demonstrated that attackers actively target vulnerabilities requiring little more than viewing a malicious email. The new CSS research expands that threat model by showing that script execution is not always necessary for an email to manipulate authenticated application state.

Email gateways may attempt to strip dangerous styling before delivery, but this should be treated as defence in depth. Rewriting every incoming HTML message safely is difficult for the same reason that webmail sanitization is difficult: browser interpretation is complex and constantly changing. Providers closer to the rendering layer are generally better positioned to enforce the final security boundary.

Security teams should also recognise that static malware scanning is unlikely to identify many of these attacks. A malicious message may contain no executable attachment, JavaScript or obvious exploit shellcode. Its payload may consist entirely of legitimate HTML and CSS features combined in a sequence that becomes dangerous only when rendered by a particular webmail client and browser.

Detection therefore requires more contextual analysis. Messages containing unusual quantities of nested selectors, CSS animations, custom properties, external resource references or UI-oriented HTML elements may deserve additional scrutiny. However, such detection is inherently imperfect because legitimate marketing email often contains extremely complicated styling as well, one of the many gifts the advertising industry has generously provided to security engineering.

The emergence of AI-connected inboxes makes sanitization even more difficult because content may now be interpreted simultaneously by a browser, a sanitizer and a language model. Each component has a different understanding of what constitutes active content. Text hidden through CSS may be irrelevant to the user interface but highly influential to the AI agent, while HTML considered visually harmless may trigger browser networking that the AI can indirectly control.

Organizations deploying AI agents with access to email should therefore treat every message body as untrusted instructions as well as untrusted data. The agent should not automatically execute actions merely because text appears inside a mailbox belonging to the user. Sensitive operations involving authentication tokens, external navigation, account changes or data transmission should require explicit authorization and should not be triggered solely by content retrieved from messages.

AI systems should also receive normalized representations of email that minimize the gap between what the user sees and what the model reads. Hidden text, zero-opacity content, pseudo-element generated strings and other invisible instructions should either be removed or clearly marked as untrusted metadata. If the human and the agent operate on different representations, attackers can deliberately target that difference.

The broader lesson from this research is that CSS has become an active security surface rather than merely a visual formatting language. Modern CSS can perform conditional selection, trigger network requests, manipulate interaction regions, expose differences in hidden values and influence how both humans and automated systems interpret content. Treating it as harmless because it does not directly execute JavaScript is no longer a safe assumption.

The research should not be interpreted to mean that simply receiving any CSS-formatted email automatically exposes passwords or accounts. The demonstrated attacks depend on particular webmail sanitization weaknesses, browser behaviours and user interactions, and several were proof-of-concept chains constructed specifically to demonstrate what becomes possible when those conditions align. No malicious exploitation of these new techniques has been reported publicly.

Nevertheless, several techniques were still functional when the research was published, including the Outlook label-jacking behaviour and Gmail `image-set()` bypass. Fastmail corrected two CSS mutation issues reported by the researcher, while the previously demonstrated Proton Mail proxy bypass no longer worked when retested. The varying vendor responses demonstrate why this should be viewed as an evolving class of problems rather than one vulnerability that can be closed with one patch.

For webmail developers, the strongest response is architectural isolation combined with restrictive sanitization. Messages should render inside sandboxed contexts that cannot interact directly with trusted application controls. CSS should be limited to the formatting functionality genuinely necessary for email, and external resource loading should be enforced through a consistent policy independent of the exact property or syntax used to request it.

For enterprises, the research reinforces the importance of keeping webmail platforms and browsers updated, restricting automatic remote content where practical and treating unusual email-driven authentication or account actions with additional suspicion. Organizations introducing AI inbox assistants must go further by treating message content as potential prompt injection and ensuring that AI agents cannot convert hostile email into privileged actions without appropriate controls.

The most significant lesson is that an email should remain an email. It should not be able to reach out of its message pane and operate the surrounding webmail interface, infer authentication tokens, create invisible instructions for an AI agent or transform the trusted application into a credential-capture surface.

HTML email has spent decades attempting to combine the freedom of the web with the security expectations of a messaging system. This research demonstrates how difficult that compromise remains. Once an application allows attacker-controlled markup to share an execution and rendering environment with authenticated controls, the distinction between content and code becomes increasingly dependent on parser behaviour that attackers are quite happy to study more carefully than anyone intended.

New research shows content inside an email can escape its message boundary and interfere with the webmail interface. Across attack chains spanning Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail, the techniques can capture passwords, take over third-party accounts, leak tokens, hijack trusted UI actions, and manipulate AI tools that read email. PortSwigger researcher Gareth

Source: New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens via The Hacker News — published 08 Aug 2026.