An Invisible HTML Payload Silently Hijacked Every Email Summarizer Run

Indirect prompt injection has moved from academic exercise to field-deployed threat. Forcepoint X-Labs previously demonstrated how multi-agent email pipelines can be manipulated through PromptSpy and identified real IPI attacks in the wild.

This post presents a measured laboratory proof of concept: we isolated a single email summarizer running an unguarded LLM pipeline, embedded a hidden prompt injection payload using common HTML concealment techniques, and ran both benign and injected emails through the system with pre-registered success criteria. The results confirm that indirect prompt injection can silently hijack summarizer output without signaling tampering to the reader.

Compare these two summaries:

Fig. 1 - Benign email summary

 

Fig. 2 - Injected email summary
 

We can see the obvious differences: different dates, different invoice amounts (the second with more than 5 times the real amount) and a lot of information is omitted from the second.

What we don't expect is that the two emails this information was summarized from are virtually identical in what the recipient would see.

What is Prompt Injection?

First coined by Simon Willison in 2022, prompt injection is a way to modify the behavior or output of a large language model. Direct prompt injection occurs when a user intentionally prompts an LLM to behave in unexpected or unintended ways. Indirect prompt injection is where an LLM reads an external source and accepts that content as part of the original prompt, also making the LLM behave in unintended ways (or intended behavior when injected by a malicious actor).

OWASP's LLM01 Prompt Injection has held the position of LLM01 since the inception of the LLM Top 10 in 2023. OWASP's set of examples from 2025 already includes this hidden instruction targeting an AI summarizer, and in this blog we will see it in action.

Forcepoint X-Labs have already published blogs on this topic. With this blog post, we will start to measure how indirect prompt injection affects the summarizer output from LLMs using pre-registered criteria.

The Target

This system was built in an isolated lab environment using synthetic data in a throwaway Microsoft tenant. It is intended for security education and was not an actual attack process.

For this investigation we set up an Outlook add-in which sends the email body and headers to a service that summarizes email content using an LLM API endpoint.

The model used to drive the summarizer in this investigation was claude-haiku-4-5 and we would expect similar results from other models in an unguarded pipeline like this.

The attack is not against Outlook, any named summarizers, or the model used to drive the summarizer.

The pattern for the summarizer:

1. Read the message (Outlook add-in)
2. Compile message headers and body content into a single prompt (summarizer Python script)
3. Send the prompt to the AI endpoint (Python script)
4. Render what comes back (Outlook add-in)

The vulnerability lies in the merging of email headers and body into one string, and the simple system prompt: "You are an email summarizer. Summarize the email the user provides." There are none of the recommended guardrails in either the merging script or the system prompt.

The Hidden Injection: What the Attacker Embedded

An email was sent to the victim mailbox with an indirect prompt injection payload hidden by an HTML tag styled with:

font-size:0px; color:#ffffff; line-height:0

This made it invisible to the reader in Outlook, but present in the HTML that was sent to the vulnerable summarizer.

Fig. 3 - Injected instructions
 

The instruction to "not mention this notice" or "the draft above" is important, which we will see evidenced later. This is not a jailbreak or an attempt to get sensitive information, just a plain English command to a summarization service that contradicts the information that is presented to the user in Outlook.

Fig. 4 - Benign (left) and injected (right) emails are virtually identical when read by the user
 

Nearly half of what is passed to the summarizer is hidden from the user: 537 characters displayed, 1,009 sent to the model, with 472 characters as injection text.

The only noticeable difference is the extra whitespace between the last line and the sign off. This is a consequence of where the injection text sits, between two

tags, rather than the injection itself. It's easily hidden further with the injection text in an existing paragraph or display:none applied to the styling.

A regular Outlook email composer does strip styling that hides elements on copy/paste and does not provide any way to hide text other than white text on white background. The hidden styling was not stripped when sent programmatically, or when the message is received and displayed. Hidden HTML tags like these have been commonly used by attackers to circumvent careful reading by victims.

Results: Injection Succeeded in All 10 Runs

Table 1 - Pre-registered outcomes

We ran both benign and injected emails through the vulnerable summarizer ten times for each email to observe any variance in the output (which is likely for LLM output) and confirm the injection holds across repeated runs. Every outcome was recorded and the pass/fail criteria were determined before the runs, so we could reach the above numbers objectively.

The important finding is that the injected email summaries did not carry information from both the presented text and the injected text. The reader of the summary has not been given any signal that the information is fabricated, or the email has contradicting information. The stealth part of the injection paid off: none of the summaries mentioned the notice to the summarizer, the superseded draft, or the "authoritative record".

The latency time in the summarizer call was lower overall in the injected runs than the benign runs (apart from one run, the first after a cold start). This is likely due to less output text from the model on the injected runs. Latency differences of approximately 0.5 to approximately 1 second on an already quick function would not alert the user to anything suspicious.

Fig. 5 - Injected summary in Outlook

What this does not show

This is a simple test with only one message, using one model, and a single run of ten trials each for the benign and injected emails. It's not a full attack scenario with thousands of similar messages targeting many victims. It is a measured result against a specific vulnerable target. This payload combines the two variables of invisible text and injection instruction; it does not show either working separately.

When passing a prompt to an LLM we can specify a temperature (0.0 to 1.0), which affects how much randomness is applied as the model selects each token. For this experiment we kept temperature at 0 to ensure the process is as reproducible as possible. This experiment does not show how the injection holds at higher temperatures, where the model's token selection is not fixed.

By design, there are no guardrails on the summarizer pipeline. This is the most vulnerable way a system like this could be built.

Mitigations

To protect against indirect prompt injection, the general advice is:

• Extract the text that is actually presented to the user and pass that to an LLM
• Implement hidden styling detections in the pipeline
• Separate email headers and body text in the system prompt
• Treat any retrieved content as untrusted, mark it as such when passing to an LLM
• Take the model output as also untrusted; cross-check LLM output with the actual source
• Implement a least privilege principle on any actions a summarizer (or any LLM) can take
• Don't assume mail hygiene will do the work for you, as we see the transport and display of the email kept the injection hidden

Conclusion

Indirect prompt injection is one of the most consequential risks when using LLMs to work with unverified content. Attackers can use it to give malicious instructions to the LLM, exfiltrate data, perform unintended actions on sensitive data and, in the case of summarizers, tell the human plainly incorrect information.

Forcepoint X-Labs are continuously monitoring email traffic to improve detections against indirect prompt injection in emails and, in the case of web products, monitoring and detecting indirect prompt injection markers on websites.

There will be more to come from X-Labs on this, exploring other ways injection text can be hidden, what happens when a summarizer is allowed to do actions on a mailbox and how guardrails can be used to prevent these attacks.