Topic starter
11/08/2026 3:12 pm
TL;DR: Webmail sanitizers can be pushed past their trust boundary, letting sanitized CSS trigger UI actions, exfiltrate tokens, and steer AI browser behaviour through indirect prompt injection, according to PortSwigger. The lesson is that email rendering, browser parsing, and identity-bearing tokens now overlap in ways traditional webmail controls do not reliably contain.
Editorial analysis by NHI Mgmt Group, based on content published by PortSwigger: “CSS:the bomb inside your inbox”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Webmail sanitization can fail when browser interpretation mutates apparently safe CSS into behaviour that crosses trusted boundaries.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
11/08/2026 3:26 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: CSS injection in webmail is breaking trust boundaries and AI browsers
This post was modified 4 hours ago by NHI Mgmt Group