You check your email every morning. You trust it. You click on messages from your boss, your bank, your favorite newsletter. But here’s the truth you don’t want to hear: every HTML email you open is executing code in a browser you didn’t know you had.
That sleek email with the fancy buttons and the embedded images? It’s not a document. It’s a web page. And the person who sent it can use that web page to spy on you, steal your credentials, or impersonate someone you trust. The worst part? You’ll never see it coming.
Security researcher Gareth Heyes recently demonstrated exactly how this works. Using nothing but CSS—the styling language that makes emails pretty—he built attacks that can exfiltrate your data, map your behavior, and even forge identities. He targeted Fastmail, ProtonMail, Gmail, Cowork, and Slack. That’s not a small list. That’s most of the modern inbox.
Treating email as a document is the single biggest security mistake of the modern internet.
Here’s the core problem: email clients that render HTML and CSS are effectively running untrusted code in an environment you trust with your most sensitive conversations. The same CSS properties that make a newsletter look beautiful can also be weaponized to send encrypted data to an attacker’s server. A single pixel can track you. A single style rule can leak your password.
Most people think the solution is to strip out CSS. Ban JavaScript. Block images. But that’s a losing game. Attackers adapt. They find new ways to hide their payloads. The real answer is simpler and more radical: treat every email as a hostile website.
And that means using a sandboxed iframe for every single message. Isolate the email completely from the rest of your inbox. No shared cookies. No access to the parent document. No way to break out. It’s the same principle that keeps your browser safe when you visit a sketchy website—except applied to the one place you never think to protect.
One of the top comments on Heyes’ article captured it perfectly: “Could you defeat this with an iframe?” Yes. And the answer is already there. The research shows that strict isolation via sandboxed iframes is the best defense. But hardly any email client implements it.
Hard isolation isn’t a UX downgrade. It’s the only way to safely have rich email at all.
I know what you’re thinking: “But I like my beautiful emails. I want to see the company logo. I want the interactive poll.” That’s fine. You can have all of that—as long as it’s locked in a cage. The moment you let email code run free in your inbox, you’re giving attackers a key to your digital life.
This isn’t a theoretical threat. It’s a class of vulnerabilities that undermines both personal privacy and corporate security. Every enterprise that uses webmail is at risk. Every person who clicks on a promotional email is a potential victim. The only responsible path forward is to demand that your email client sandboxes every message as an untrusted iframe.
So the next time you open your inbox, remember: you’re not reading letters. You’re browsing a web. And that web is full of bombs.
FAQ
Q: Isn't this just theoretical? My email client is safe.
A: It's not theoretical. Security researcher Gareth Heyes demonstrated real, working attacks against Fastmail, ProtonMail, Gmail, Cowork, and Slack. CSS-based exfiltration has been proven in the wild. Your client may protect you from some attacks, but the fundamental architecture of trusting email HTML is the problem.
Q: What should I do right now to protect myself?
A: Switch to plain text mode in your email client if possible. For HTML emails, use a client that supports sandboxed iframes (like some modern webmail interfaces). If you're an IT admin, enforce strict Content Security Policy and consider email isolation solutions. The long-term fix is demanding that email clients treat every message as an untrusted iframe.
Q: Isn't this overblown? CSS is just styling, it can't do real harm.
A: CSS is Turing-complete in some contexts and can absolutely exfiltrate data. For example, CSS can use background-image URLs to send data to an attacker's server, or use attribute selectors to guess password characters. The risk is real, and the industry has been slow to adapt. Don't underestimate the power of a well-crafted stylesheet.