New research into webmail security shows that CSS content in email is not only a display issue. Under certain conditions, malicious CSS can escape the boundaries of a message, affect the webmail interface, and create paths to steal passwords, tokens, or manipulate user actions.
According to The Hacker News, PortSwigger researcher Gareth Heyes demonstrated attack chains targeting several popular webmail services, including Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail, and AOL Mail. The common thread is that attackers abuse how browsers handle HTML, CSS, and interface components inside the mail-reading environment to turn a seemingly passive email into an interactive attack surface.
The problem sits at the boundary between email and application
Modern webmail is a full web application. When a user opens an email, the message content is placed inside the service interface, alongside sign-in buttons, navigation bars, preview panes, security warnings, and AI-integrated components. If content isolation is not strict enough, CSS inside the message can influence areas outside the email body.
At its core, this is a context-separation problem. Webmail providers must allow email to render well enough for users to read invoices, newsletters, or work documents, while also blocking any code, attributes, and style rules that could break the safe display area. That balance becomes harder as web standards continue to expand.
Observed attack scenarios
In one attack chain targeting Outlook, CSS could be used to mimic or overlay part of the Microsoft login interface, making users believe they are interacting with a legitimate service component. If the fake interface is convincing enough, victims may enter passwords or perform sensitive actions directly inside the webmail session.
In another direction, the research showed that some CSS techniques can trigger outbound requests to an attacker-controlled server. For Gmail, The Hacker News cited a case involving image-related CSS behavior to generate network requests from malicious email content. Although exploitability depends on each service's filtering and configuration, the key point is that CSS can become a signal-leakage channel.
Other chains involved manipulating trusted interface elements, misleading AI email readers, or causing users to take actions they do not realize are being guided. This expands the traditional concept of phishing: instead of merely sending a fake link, attackers can try to bend the very interface users trust.
Why ordinary users struggle to recognize it
Most users cannot distinguish the technical boundary between email content and the webmail interface. When a dialog, confirmation button, or login screen appears on the same familiar page, the natural reaction is to trust that it belongs to the service. That is a major advantage for interface-based attacks.
In addition, CSS does not feel as dangerous as an executable file or a macro. Many people see CSS as only a layer for colors, layout, and fonts. In practice, modern CSS can control positioning, overlays, visibility states, external resource loading, and complex interactions with page structure. When placed in an environment that is not tightly constrained, it can support sophisticated deception.
Business impact
The first risk is theft of credentials and session tokens. If an email can lead users to a fake interface inside webmail itself, security teams cannot rely entirely on signs such as the domain in the address bar, because the user is still inside a familiar service.
The second risk is data leakage through network requests or interaction with external components. Even if the message does not run JavaScript, an image request or secondary resource triggered at the right moment can reveal state, identifiers, or email-opening behavior.
The third risk affects AI tools inside the mailbox. When an AI assistant reads, summarizes, or acts on email, intentionally crafted content can try to influence how the tool interprets context. As a result, webmail protection is no longer just spam filtering; it also means protecting the interface layer and automation layer.
Defensive Lessons
For service providers, the key priority is to isolate email content with appropriate sandboxing, sanitize CSS through an allowlist, block attributes that can overlay the interface, control external resource loading, and test new components with an interface-attack model. Small changes in browsers or rendering libraries should also be reassessed in the webmail context.
For enterprises, user training should be strengthened around realistic scenarios: do not re-enter passwords or authentication codes from a dialog that appears after opening an email; prefer opening login pages from bookmarks or a password manager; and report emails that show login forms, unusual confirmation buttons, or sudden permission requests.
Security teams should also monitor for unusual login events after users open suspicious emails, deploy phishing-resistant authentication such as FIDO2, limit session-token lifetimes, and control permissions for AI integrations in the mailbox. These measures reduce damage even if one layer of email filtering is bypassed.
Conclusion
CSS attacks in webmail show that the boundary between content and application is becoming increasingly important. An email does not need to contain traditional malware to create risk if it can affect the interface users trust. In workplaces that depend on email, browsers, and AI, effective defense requires content filtering, interface isolation, phishing-resistant authentication, and independent verification habits from users.
VNCyberS compiled from The Hacker News and PortSwigger
Tiếng Việt
English