Hidden HTML hijacked AI email summaries in 10 of 10 runs

If you have wired an LLM into your inbox — a summarizer, a triage bot, an agent that reads support mail and opens tickets — the attacker does not need your password. They need one email with text your team cannot see. Forcepoint X-Labs published a lab writeup this week showing exactly that: hidden HTML prompt injection that hijacked an AI email summary in 10 out of 10 runs.

What actually happened

Per Forcepoint X-Labs (published August 25, 2026), researchers built an isolated Outlook add-in that shipped email headers and body to an LLM summarization service, using Claude Haiku 4.5 at temperature 0 for reproducibility.

The payload was styled font-size:0px; color:#ffffff; line-height:0. To a human in Outlook, the message was 537 characters of ordinary business email. The model received 1,009 characters — 472 of them a hidden instruction block the reader never saw. Roughly 47% of what the model read was invisible to the person it was summarizing for.

Ten benign runs, ten injected runs. Every injected run hit all three pre-registered criteria: the summary reported an invoice of EUR 46,200 instead of the real figure (over five times larger), it invented dates, and it dropped the actual sender's name. No error. No warning. The summary just quietly said something else.

That is the part worth sitting with. This was not a jailbreak that produced obvious garbage. It produced a clean, confident, wrong summary — the kind someone forwards to accounts payable.

Why it matters for your business

Indirect prompt injection is not a model bug you can wait out with a version bump. It is a plumbing problem: your pipeline handed raw HTML to a model that has no way to tell "content the sender wants read" from "instructions the sender wants followed."

Forcepoint's own mitigation list is the build spec, and it is all pre-model work. Extract only the visible text before the LLM ever sees it — strip zero-size fonts, white-on-white color, zero line-height, hidden divs, and off-screen positioning. Keep headers and body in separate, clearly-labeled prompt sections so a body payload cannot impersonate a header. Treat every retrieved byte as untrusted. Validate the output against the source: if the summary names a number, that number should exist in the visible text, and a mismatch should stop the flow, not decorate it.

And cap the blast radius. A summarizer that only summarizes is an accuracy problem. A summarizer that can also open a ticket, mark an invoice approved, or reply on your behalf is an authorization problem. Microsoft now ships prompt injection protection in Defender for Office 365 — worth turning on, and still not a reason to skip sanitizing your own input.

Sources: Forcepoint X-Labs, Microsoft Learn.