As reported by Security Affairs, PortSwigger researcher Gareth Heyes has demonstrated a class of attack that deserves far more attention than it has received: weaponized CSS targeting webmail platforms and, critically, the AI-powered tools that are increasingly bolted onto users' inboxes.
Why CSS as an Attack Vector Is So Dangerous
The security community has long debated what HTML-capable email clients can and cannot safely render. CSS injection has historically been treated as a lower-tier concern — a design nuisance rather than a serious threat. This research fundamentally reframes that assumption. CSS, when rendered within a privileged email context, can be used to probe the DOM, exfiltrate attribute values, and trigger external requests — all without a single line of JavaScript.
What makes this particularly insidious is the trust model at play. Email clients strip JavaScript aggressively and for good reason, but CSS has often been treated as benign collateral. Security teams have not historically built detection rules or content policies around malicious stylesheet behavior the way they have for script injection.
The attacker's advantage: CSS-based exfiltration is low-noise, bypasses most JavaScript-focused XSS defenses, and can be embedded directly in HTML email bodies that pass spam filters and AV scanners with minimal friction.
The AI Multiplier Effect
The more alarming dimension of this research is its intersection with AI email assistants. Products like Google's Gemini-in-Gmail, Microsoft Copilot for Outlook, and a growing ecosystem of third-party inbox AI tools are being granted broad read — and in some cases write — permissions over user mailboxes. These tools often process raw email content to generate summaries, draft replies, or surface action items.
If an attacker can craft a malicious email that manipulates how the AI interprets or summarizes its content, the attack surface expands dramatically. Consider the following threat scenarios:
Who Is Most at Risk
This is not a theoretical concern limited to security researchers. The risk is highest for:
- Enterprise users of AI email productivity tools — particularly those with OAuth-connected third-party assistants that have broad inbox permissions
- Organizations in high-value verticals — finance, legal, healthcare, and executive offices where inbox compromise has outsized consequences
- Anyone using webmail via browser rather than a hardened native client, due to the richer DOM environment available to CSS manipulation
- Developers and vendors building AI inbox integrations — who may not be applying the same scrutiny to CSS rendering as they do to script injection
The Deeper Structural Problem
This research exposes a fundamental tension in how AI tools are being layered onto legacy communication infrastructure. Email was designed in an era when the threat model was simple. Webmail clients added complexity. AI assistants added another layer of data processing — often developed on accelerated timelines with insufficient adversarial testing. Each layer inherits the weaknesses of those beneath it, and attackers are beginning to exploit that stacking.
The AI security community has focused heavily on prompt injection via user-controlled inputs. Less attention has been paid to email-borne prompt injection, where the attacker has no direct access to the AI interface but can still influence the model's behavior through crafted content delivered to the inbox.
Shield53 Recommendations
For Security Teams and CISOs
- Audit AI email integrations immediately. Identify every third-party or native AI tool with inbox access in your environment. Review OAuth scopes — read-only access is preferable to read/write where possible.
- Review your email client's CSS rendering policy. Work with your webmail vendor or internal development team to understand what CSS properties are permitted in rendered email bodies. Push for restrictive allowlists.
- Implement Content Security Policy (CSP) headers on any internally developed or self-hosted webmail interfaces. Ensure
style-srcdirectives are explicitly configured. - Treat AI-generated email summaries as untrusted output. Educate users — especially executives and finance staff — that AI-generated summaries can be manipulated and should not substitute for reviewing original message content before taking action.
- Include email-borne prompt injection in your threat model. Red team exercises and phishing simulations should begin incorporating AI manipulation scenarios, not just credential harvesting.
For Developers Building AI Email Features
- Strip or sandbox CSS before passing email content to AI model context windows.
- Apply output validation to AI-generated summaries — flag or block content that contains URLs, financial instructions, or credential requests that weren't present in a sanitized version of the original email.
- Follow OWASP's emerging guidance on LLM security, particularly around indirect prompt injection via untrusted data sources.
CSS has always been more powerful than its reputation suggests. In the age of AI-assisted email, treating it as a low-risk concern is no longer acceptable. The attack surface is real, the techniques are practical, and the tools to exploit them are well within reach of motivated threat actors.