Notifications
Clear all
Topic starter
11/08/2026 3:10 pm
TL;DR: Webmail clients often render untrusted CSS inside trusted inbox UIs, and sanitisation gaps can let attackers turn styling into a data-exfiltration primitive, according to PortSwigger. The lesson for identity and access teams is that mailbox trust boundaries, not just message content filters, now need stronger policy and runtime scrutiny.
NHIMG editorial — based on content published by PortSwigger: CSS: the bomb inside your inbox
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
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 can authenticated webmail still be unsafe for sensitive communications?
A: Authentication proves the user is allowed into the mailbox, but it does not prove the rendering environment is trustworthy.
Q: What do security teams get wrong about CSS sanitisation?
A: They often assume that removing scripts makes the problem safe enough.
Practitioner guidance
- Harden CSS sanitisation and rendering rules Review which CSS properties, selectors, and remote fetch behaviours are allowed in webmail.
- Isolate email rendering from authenticated application context Use sandboxing, separate origins, or hardened viewer components so untrusted mail content cannot reach the same browser privileges as core identity sessions.
- Test webmail clients for non-script exfiltration paths Add CSS-driven conditional rendering, image fetch side effects, and layout-based inference to your secure testing programme.
What's in the full report
PortSwigger's full research covers the exploit mechanics and client-specific rendering behaviour this post intentionally leaves at the source:
- Step-by-step analysis of the CSS sanitisation assumptions that webmail clients rely on
- Technical examples showing how style-driven side channels can leak data without script execution
- Client behaviour differences that determine whether the attack succeeds in practice
- Hands-on exploit discussion that helps defenders reproduce and validate the failure mode
👉 Read PortSwigger's research on CSS exfiltration inside webmail clients →
CSS in webmail clients: are your inbox controls keeping up?
Explore further
11/08/2026 3:25 pm
CSS sanitisation is now a trust-boundary control, not a rendering nicety. Webmail clients that accept attacker-controlled styling are making a security decision about what can run inside a trusted session. That decision affects data exposure, phishing resilience, and the integrity of identity-linked mailbox workflows. Practitioners should treat inbox rendering as part of the attack surface and not as a passive presentation layer.
A question worth separating out:
Q: Who is accountable when a webmail client leaks data through rendered content?
A: Accountability usually spans application security, platform owners, and the team managing the identity-linked mail environment. If the client renders attacker-controlled content inside a trusted session, then both the rendering policy and the browser boundary should be treated as governed controls under the organisation's security framework.
👉 Read our full editorial: CSS in webmail inboxes creates a silent data exfiltration path
