PortSwigger researcher Gareth Heyes has shown that a malicious email can abuse allowed or imperfectly sanitized CSS to influence the trusted webmail interface around the message. The demonstrated chains range from tracking when an email is viewed to placing attacker-controlled content over the page, redirecting clicks, and building a fake sign-in form that captures a password without JavaScript.
This does not mean that opening any email automatically steals a password. Different demonstrations targeted different products and browsers, and several need the recipient to click, paste, or type into a spoofed control. Some issues were fixed during disclosure; the report says other behaviors remained at publication. The practical warning is simpler: a login box that appears inside an opened message is not trustworthy just because the browser address bar still shows the real mail provider.
How CSS can cross the email boundary
Webmail has to display untrusted HTML inside a trusted application. Providers normally remove scripts and filter CSS before rendering the message. The new research focuses on gaps between what a sanitizer considers safe and what a browser later builds from that markup.
Heyes demonstrated several ways that gap can matter. HTML labels can activate interface controls outside the message. CSS selectors and generated content can cover trusted controls or redirect a click. Browser parsing can also mutate escaped CSS after a filter has approved it, allowing a rule to affect more of the page than intended. Once an attacker controls the surrounding layout, a password prompt can be drawn inside the mailbox and made to behave like a sign-in screen.
One Outlook demonstration combined a CSS gadget with Firefox behavior to create a real-time password logger. Fastmail demonstrations used CSS mutation and “hotwiring” to turn a click anywhere on the page into a different interface action. The report also describes image-proxy bypasses in multiple mail services, but it does not present one universal exploit that works identically against every provider.
What action creates the risk?
| What happened | Risk and what to do |
|---|---|
| You only viewed the message | Do not panic. Some tracking or external-resource requests may occur on view, but password theft in the demonstrated login-spoofing chains requires more interaction. Close the message, update the browser or mail app, and watch for an unexpected sign-in prompt. |
| You clicked inside a strange or visually broken message | A CSS overlay can redirect a click to another control. Check whether the message was pinned, moved, marked, or opened a new page. Do not continue through a login panel that appeared inside the message. |
| You pasted a token or sensitive text into an email draft | Treat the pasted value as potentially exposed. Revoke a secret or session token when it has security value, then review the draft, connected apps, and account activity. |
| You typed a password into a form shown inside webmail | Assume the password was captured. Navigate to the provider through a fresh tab or official app, change it, revoke other sessions, and inspect forwarding rules, recovery methods, MFA, and app access. |
The distinction matters because a normal phishing checklist often focuses on links leaving the mailbox. The broader phishing-email recognition guide still applies, but this research adds a new rule: do not trust a credential form simply because it appears without leaving the legitimate webmail domain.
How to recognize a CSS-generated login trap
- A sign-in form appears immediately after opening or clicking inside one message, while the rest of the mailbox remains visible behind it.
- The prompt claims that the session expired but the provider did not independently reload or navigate to its normal authentication page.
- The page layout changes, a message covers the toolbar, or clicking a blank area performs an unrelated mailbox action.
- The prompt behaves differently in another browser, in the provider’s mobile app, or after reopening the service from a bookmark.
- The browser’s password manager does not recognize the field as the provider’s normal login form.
If a mailbox suddenly asks for credentials, close the tab instead of typing. Open a fresh tab, use a saved bookmark or the provider’s official app, and check account status there. A real reauthentication request should survive that independent navigation; a form created by message content will not.
What to do after entering a password
- Use an independent path. Open the provider from a bookmark or official app. Do not use a button, link, or form from the suspicious message.
- Change the password. If it was reused anywhere else, replace those copies with unique passwords as well.
- Revoke sessions and app access. Sign out other sessions, remove unrecognized OAuth applications, and review recent logins, devices, locations, and security events.
- Check mailbox persistence. Inspect forwarding addresses, inbox rules, delegates, recovery email and phone, aliases, app passwords, and recently deleted messages.
- Strengthen authentication. Add phishing-resistant MFA or a passkey where supported. Remove an unknown method before adding a replacement.
- Notify the organization. Work-account users should contact their security or help-desk team from a separate trusted channel so administrators can preserve logs and review related accounts.
The hacked-account recovery checklist covers the wider sequence when the attacker has already changed security settings or contacted other people from the mailbox. If the issue involves a self-hosted webmail product rather than a cloud service, administrators should also compare the incident with prior real-world Roundcube exploitation and verify that the server is fully patched.
What webmail developers should change
The report recommends strict isolation of message content, preferably in sandboxed frames, so untrusted markup cannot style the trusted application. Sanitizers should block external resource requests, dangerous selectors and interactive elements that are not needed for email, and revalidate any CSS that a browser parser has transformed. Developers also need to test application libraries for “gadgets” that take an allowed message attribute and append more powerful styles to the surrounding page.
For organizations, patching remains necessary but not sufficient. A gateway can remove active content, yet the final safety boundary belongs to the webmail renderer. Security testing should therefore include malicious but script-free HTML/CSS, multiple browsers, image-proxy behavior, and the exact application components that touch sanitized message content.
FAQ
Can simply opening an email steal my password through CSS?
The PortSwigger report includes view-based tracking techniques, but its password-capture demonstrations require the user to interact with a spoofed control, such as clicking or typing. Product, browser, and patch conditions differ, so opening a message is not by itself proof that a password was stolen.
Does blocking JavaScript stop this attack?
Not completely. The research specifically shows that HTML and CSS can influence interface actions and build a credential trap without JavaScript. Removing scripts is important, but webmail also has to isolate and strictly filter untrusted styles and elements.
Should I change my password after only viewing the message?
Usually not on that fact alone. Change it if you typed it into an unexpected form, approved an unknown sign-in, saw an unfamiliar session, or another reliable indicator shows account access. If you only viewed the message, close it, update the client, and monitor account activity.
References
- Heyes, Gareth. “CSS: The Bomb Inside Your Inbox.” PortSwigger Research, published August 6, 2026; accessed August 8, 2026. technical research report.
- PortSwigger. “css-the-bomb-inside-your-inbox.” GitHub, supporting materials for the Black Hat USA 2026 research; accessed August 8, 2026. official research materials.
