Notifications
Clear all
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.
NHIMG editorial — based on content published by PortSwigger: CSS: the bomb inside your inbox
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read PortSwigger's analysis of CSS injection in webmail and AI browsers →
CSS injection in webmail: are your inbox controls keeping up?
Explore further
11/08/2026 3:26 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: CSS injection in webmail is breaking trust boundaries and AI browsers
