CSS injection in webmail is breaking trust boundaries and AI browsers

At a glance

What this is: NHI Mgmt Group's analysis, drawing on PortSwigger's research: CSS injection in webmail can cross trust boundaries, steer browser behaviour, and expose tokens or other secrets.

Why it matters: IAM and security teams need to treat webmail rendering as an identity-adjacent attack surface because HTML, CSS, browser automation, and session-bearing tokens can interact in unsafe ways.

Context

Webmail clients often treat untrusted email as if it can be safely displayed after sanitization, but this article shows that the boundary is much weaker than many defenders assume. Once browser parsing, CSS interpretation, and embedded UI controls interact, an attacker can move from visual manipulation into token exposure and account-relevant actions.

The practical governance issue is not just sanitizing markup, but deciding what the mailbox is allowed to influence inside the broader browser session. Where AI browsers and identity-bearing workflows are involved, an email can become a control plane for actions the user never explicitly intended.

Key questions

Q: What breaks when webmail sanitization assumes rendered CSS is still safe?

A: The control breaks when the browser rewrites or interprets CSS differently from the sanitizer’s source view. That mismatch can turn harmless-looking markup into UI manipulation, secret exposure, or prompt injection. Security teams need to test the rendered result, not just the filtered input, because the dangerous behaviour appears after interpretation, not before.

Q: Why do sanitized emails still create risk for browser sessions and tokens?

A: Because the email can influence the same browser context that holds authenticated state, trusted UI, or clipboard content. If the message can steer clicks, focus, or outbound requests, it can reach session-bearing material even without traditional script execution. The risk is not the email alone, but the email inside a live authenticated workflow.

Q: What are the signs that AI-assisted email actions are too trusted?

A: A warning sign is when the assistant can act on email content without a strict boundary between what the user sees and what the model reads. Another is when hidden text, styling tricks, or rendered context changes can alter the assistant’s behaviour. If a message can change the assistant’s interpretation, the trust model is already too loose.

Q: Should organisations treat webmail and AI browsers as one trust boundary?

A: Yes, when the browser, mailbox, and assistant all operate on the same content stream. Separating them only on paper leaves room for CSS mutation, UI spoofing, and indirect prompt injection to cross the boundary in practice. The safer model is to govern rendering, assistant context, and action approval as one chain of control.

Technical breakdown

How CSS sanitization fails when the browser rewrites the payload

Webmail sanitizers usually inspect HTML and CSS before rendering, but browsers do not always preserve the text exactly as received. CSSOM processing, selector rewriting, escape decoding, and mutation during interpretation can turn apparently harmless input into something that targets different elements or escapes a sandboxed scope. That means the security decision is being made on source text, while the browser enforces behaviour on interpreted output. If those two views diverge, the sanitizer has certified one object and the browser has executed another. In webmail, that divergence can affect trusted UI, message content, and anything reachable from the same rendering context.

Practical implication: Treat browser re-interpretation as part of the attack surface, not just sanitizer logic.

Why HTML labels and CSS gadgets can trigger trusted UI actions

HTML labels are dangerous in sanitised email because the label-to-control relationship can inherit the click behaviour of the targeted element. If a sanitizer allows labels and does not tightly constrain the for attribute, an attacker can map email content onto form controls that live inside the trusted mail client UI. That turns a message into an interaction primitive rather than a passive document. CSS and HTML gadgets amplify the problem by letting the attacker create lookalike controls, hide text, or steer focus. The result is not merely spoofing. It is control flow inside the interface that the user believes is protected by the mail client boundary.

Practical implication: Block UI-binding gadgets that let email content activate or redirect trusted interface controls.

How indirect prompt injection in AI browsers changes the email threat model

AI browsers add a new parsing layer between the user and the rendered page. If an email can hide one version of the content from the human and a different version from the model, the attacker can steer the model with instructions the user never sees. In this article, that is achieved through CSS tricks such as pseudo-elements and opacity so the large language model interprets a different prompt context than the victim perceives. This is not classic phishing alone. It is prompt smuggling through rendered content, where the browser, the AI layer, and the email client all participate in the attack path.

Practical implication: Separate user-visible content from model-readable context before allowing AI-assisted actions on email.

Threat narrative

Attacker objective: Use trusted email rendering to steal credentials or tokens and to influence browser or AI-assisted actions without user awareness.

1. Entry occurs when a crafted email is rendered inside a webmail client that allows enough HTML and CSS to survive sanitization.
2. Credential or session data becomes exposed when browser interpretation, CSS mutation, or UI gadgets create access to tokens, pasted secrets, or account-bearing workflows.
3. Escalation happens when the same rendering context is used to drive trusted UI actions, indirect prompt injection, or outbound requests that reveal sensitive data.
4. Impact is account compromise, token theft, or manipulation of AI browser behaviour through content the victim did not intend to execute.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Webmail sanitization is no longer just a content-filtering problem. Once CSS can mutate during browser interpretation, the defender is no longer evaluating the same object the user eventually sees. That creates a trust-boundary mismatch between source markup, rendered DOM, and the higher-value actions the mailbox can trigger. Practitioners should treat this as a governance failure in the rendering pipeline, not a narrow HTML filtering issue.

Identity-bearing browser sessions are now part of the email attack surface. Tokens, pasted credentials, and authenticated workflows can all be influenced when email content interacts with trusted UI in the same browser context. This is where IAM and NHI concerns intersect with front-end security: a message can become a path into session-bearing state if rendering controls are too permissive. The right security model assumes email is adversarial even after sanitization.

AI browsers introduce a new prompt integrity problem inside ordinary communications. If the model and the human do not consume the same content, trust in the assistant becomes a security boundary problem rather than a usability feature. That makes prompt isolation, model-visible content controls, and action confirmation part of identity governance for assisted browsing. Practitioners should assume indirect prompt injection will target the gap between what the user reads and what the model executes.

Content mutation is the named concept defenders should watch for here. The article is not only about CSS injection, but about safe-looking content mutating into unsafe behaviour after sanitization. That pattern matters because security review often stops at pre-render checks, while the real risk emerges after the browser and assistant layers reinterpret the payload. The control objective is to govern what the browser can turn the message into, not merely what the sanitizer accepts.

Webmail is becoming a control plane for adjacent systems. The more an inbox can influence browsers, AI assistants, and authenticated web applications, the more it behaves like a high-trust orchestration surface. That should push security teams to reassess mailbox permissions, rendering policies, and assistant integrations together rather than as separate stacks. The programme implication is to govern the path from email to action as one end-to-end trust chain.

What this signals

Content mutation is the control gap here: the security decision is made on source markup, but the exploit lands after browser interpretation changes what that markup means. That gap is especially important for email systems that also feed AI assistants, because the assistant may consume a different effective message than the human user.

For IAM and NHI teams, this widens the definition of identity-adjacent risk. Tokens, clipboard data, and action-bearing browser sessions can be influenced by content that is supposed to be passive, so inbox governance now belongs in the same conversation as session protection and assistant safety.

For practitioners

• Tighten email rendering allow lists Review which HTML and CSS constructs are actually needed for business mail and remove UI-binding elements such as labels, interactive selectors, and risky pseudo-class behaviour.
• Constrain AI browser access to email content Do not let AI-assisted browsing consume raw rendered mail without a content boundary that separates human-visible text from model-visible instructions.
• Test for sanitizer and browser mismatch Build test cases that compare sanitizer output against real browser rendering so escaped CSS, selector rewriting, and mutation paths are visible before deployment.
• Block message-driven trusted UI actions Prevent email content from activating controls in the surrounding client interface, especially actions that can pin, toggle, focus, or submit.
• Review image and outbound request handling Use proxying and strict request controls so rendered mail cannot quietly leak data through image loads, background requests, or other remote fetches.

Key takeaways

• Webmail sanitization can fail when browser interpretation mutates apparently safe CSS into behaviour that crosses trusted boundaries.
• The article demonstrates that email content can drive UI actions, token exposure, and prompt manipulation when rendering layers are too permissive.
• Security teams should test rendered behaviour, constrain AI browser context, and block email-driven trusted actions in the same control review.

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.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• 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.
• Content Mutation: Content mutation is the security-relevant change that occurs when rendered output no longer matches the original source after parsing or transformation. It matters because defenders may approve the input while the browser or model acts on a different, more dangerous interpretation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to adjacent browser and workflow risks that now influence access and action boundaries.