CSS injection in webmail is breaking trust boundaries and AI browsers

At a glance

What this is: This is an analysis of how untrusted CSS in webmail can cross trust boundaries and enable token theft, UI abuse, and AI browser manipulation.

Why it matters: It matters because inbox rendering is now an identity attack surface, where a weak sanitization boundary can expose secrets, hijack sessions, and undermine both human and machine-operated workflows.

👉 Read PortSwigger's analysis of CSS injection in webmail and AI browsers

Context

Webmail clients have to render hostile HTML and CSS inside a trusted interface, which makes sanitization a security boundary rather than a formatting feature. Once the browser, the sanitizer, and embedded content disagree about what is safe, an attacker can turn email rendering into UI manipulation, token exposure, and credential theft.

The identity angle is real because the targets in this class of attack are not just pixels but the credentials, OAuth tokens, and session artifacts that represent user and workload access. That makes webmail a governance problem for IAM, secrets management, and any programme that assumes the inbox is only a delivery channel, not an execution surface.

Key questions

Q: How should security teams handle untrusted CSS in webmail clients?

A: Security teams should treat untrusted CSS as executable logic for the purposes of risk assessment. That means testing what the stylesheet can infer, fetch, or conditionally reveal inside a logged-in mailbox session, then constraining those behaviours through sanitisation, sandboxing, and outbound request controls.

Q: Why do AI browsers create new risk from malicious email content?

A: AI browsers can consume the same email differently from the user, which means hidden instructions or shaped context can steer model behaviour. That turns ordinary message content into a delegated action channel. Security teams should assume prompt injection and UI manipulation can occur through formatting alone, especially when the agent can open tabs or act on identity data.

Q: What breaks when a webmail sanitizer only checks source HTML?

A: Source-only inspection fails when the browser normalizes or mutates the markup into something different from what the sanitizer approved. That can let hidden selectors, escaped syntax, or pseudo-elements survive in an effective form that changes the rendered behaviour. The result is a trust gap between policy and execution.

Q: Who is accountable when a stolen token is reused for business email compromise?

A: Accountability usually spans identity, email security, and SaaS owners because the compromise sits at the boundary between authentication and delegated access. Organisations should assign explicit ownership for token revocation, consent monitoring, and session invalidation so a valid token cannot become an indefinite trust grant.

Technical breakdown

How CSS sanitization fails in webmail

Webmail sanitizers usually whitelist HTML and CSS features, then try to strip anything dangerous before rendering. The problem is that browser parsing, CSS object model mutation, and sanitizer logic do not always agree on the final structure. A rule that looks harmless in source form can become different once escapes are decoded, selectors are rewritten, or pseudo-elements are applied. That creates a trust gap between what the defender inspected and what the browser executes. In the article's examples, that gap is enough to influence UI state and leak information through allowed styling primitives.

Practical implication: treat browser interpretation as the security boundary and test the post-rendered DOM, not just the submitted HTML.

Why CSS can trigger UI actions and data exposure

CSS is not supposed to execute script, but it can still control visibility, layout, focus, and element targeting. When sanitizers allow labels, selectors, or pseudo-classes, an attacker can steer clicks, surface hidden elements, or imitate a trusted control path inside the page. That becomes dangerous in webmail because the message body shares a visual context with the application chrome. If the attacker can influence focus, hover, or display state, they can manipulate user actions or route data into an attacker-controlled sink without needing traditional script execution.

Practical implication: restrict interactive CSS features that can affect trusted UI, especially selectors and label-based interaction paths.

How indirect prompt injection affects AI browsers

AI browsers introduce a second interpreter into the email flow. The human sees one presentation layer, while the model consumes a different textual or structural view, especially when CSS hides or reshapes content. That makes indirect prompt injection possible through content that appears benign to the user but carries instructions for the agentic browser. In the article's example, the email content is used to influence browsing behavior, open tabs, and leak identity-relevant data. This is not ordinary phishing. It is a delegated execution problem where the agent accepts manipulated context from untrusted content.

Practical implication: treat AI browsing assistants as identity-bearing automation and gate their actions on trusted, minimal input.

Threat narrative

Attacker objective: The attacker wants to convert trusted email rendering into a path for token theft, account compromise, and control of browser-mediated actions.

1. Entry occurs when an attacker sends malicious HTML and CSS through a webmail channel that the client attempts to sanitize but still renders inside a trusted UI.
2. Credential access follows when the crafted content manipulates labels, selectors, clipboard content, or indirect prompts to expose tokens, session material, or identity data.
3. Impact is achieved when the attacker exfiltrates credentials, hijacks browser behaviour, or alters trusted UI actions to control accounts or steal passwords.

NHI Mgmt Group analysis

Webmail CSS sanitization is now an identity control, not a presentation control. The article shows that email styling can influence UI state, prompt handling, and token exposure. That means the real risk sits at the boundary between content rendering and identity-bearing actions. For IAM and secrets teams, the lesson is that trusted inbox rendering can no longer be treated as a low-risk display layer.

Indirect prompt injection is the bridge between classic webmail abuse and agentic AI risk. Once an AI browser can consume attacker-shaped email context, the message body becomes a delegated instruction channel. That creates a governance gap that existing human-centric phishing controls do not cover. Practitioners need to assume that agentic tooling can be steered through content formatting alone, especially when the model and the user do not see the same thing.

Label-based UI abuse is a named control gap: trusted control inheritance. The article's Outlook example shows that a label can inherit click behaviour from a form element the user never intended to activate. That is a specific failure mode, not a generic XSS issue. It tells security teams to review all message-rendered interaction paths, because inherited trust can be enough to trigger account-impacting actions.

CSS mutation creates a post-sanitization drift problem. Sanitizers that inspect source text but miss browser-normalized output are vulnerable to a mismatch between approved content and effective content. This is the same class of issue that breaks reliable policy enforcement in other parsing-heavy systems. In governance terms, the control failed because the inspected artifact was not the executed artifact, which means teams need post-render validation and stricter feature denial.

The primary defensive mistake is assuming email content is passive. In this threat model, email is an active delivery mechanism for UI manipulation, data exfiltration, and agent steering. That is why mailbox security, browser hardening, and identity governance now overlap. Practitioners should treat untrusted email as executable context, especially where OAuth tokens, session cookies, or AI assistants are involved.

What this signals

Inbox rendering now sits inside the identity attack surface. Once tokens, session artifacts, and AI-assisted workflows can all be influenced through email content, teams need to govern mail clients as part of access control rather than just as communications tools. The practical signal is that secrets handling, browser hardening, and mailbox policy must be evaluated together, especially where token exposure is already common.

Trusted-control inheritance is the concept security teams should watch. When a rendered label, selector, or hidden prompt can cause a trusted action, the boundary between content and command has already failed. That has direct implications for agentic AI, because the assistant may act on the wrong layer of truth. Programmes that rely on real breach patterns should expect more attacks that blur rendering, identity, and automation.

If your organisation is adopting AI browsers or inbox assistants, set policy around what content they can interpret, what actions they can take, and which identity artifacts they can touch. The governance model should assume that untrusted email can be transformed into a control input before any human review occurs.

For practitioners

• Harden the sanitizer against interactive CSS Block or strictly limit labels, advanced selectors, pseudo-classes, and other CSS features that can influence trusted UI or inherit click behaviour from hidden controls.
• Validate rendered output, not source markup Inspect the browser-normalized DOM and CSSOM after parsing so that escaped or mutated syntax cannot slip through source-based allow lists.
• Separate email rendering from identity-bearing actions Keep OAuth token handling, session use, and account-level actions outside any inbox view that processes untrusted HTML or AI-generated context.
• Constrain AI browser permissions Require explicit trust gates before an AI assistant can open tabs, follow instructions embedded in email, or act on content that may have been shape-shifted by CSS.

Key takeaways

• Webmail CSS sanitization can fail as an identity control because the browser may execute a different effective structure from the one the sanitizer approved.
• The article demonstrates a real path from email rendering to token exposure, UI abuse, and AI browser steering, which widens the attack surface beyond classic phishing.
• Security teams should treat untrusted email as active content and separate rendering, secrets, and agent permissions before those boundaries are crossed.

Key terms

• CSS sanitisation: CSS sanitisation is the process of removing or constraining stylesheet features that could be abused when untrusted content is rendered. In webmail, it must account for more than visual styling because selectors, fetches, and layout effects can all become security-relevant behaviours.
• CSSOM mutation: CSSOM mutation is the change that can occur when a browser parses or normalizes stylesheet syntax into its in-memory object model. A rule that appears safe in source form may become dangerous after decoding or rewriting, which creates a gap between sanitiser output and actual rendered behavior.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Trusted UI Inheritance: Trusted UI inheritance is the condition where untrusted content is rendered inside a user interface that already carries organisational or product trust. In AI workflows, this matters because users may treat assistant-rendered links, warnings, or images as authoritative even when they originated on a third-party page.

What's in the full report

PortSwigger's full article covers the exploitation details this post intentionally leaves at a higher level:

• Step-by-step examples of CSS sanitization bypasses across major webmail clients and browser behaviors
• Concrete payload patterns for label-driven UI actions, token exfiltration, and indirect prompt injection
• Proof-of-concept techniques for CSS mutation, image proxy bypasses, and email-view tracking
• Additional exploitation paths including password theft and keylogger concepts

👉 The full PortSwigger article covers payload examples, mutation paths, and browser-specific bypass details

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security decisions their programmes depend on.