Document-borne AI worms can self-propagate through Copilot for Word

Context Collapse, Part 3 - AI Worming through Word

I would like to thank Microsoft product teams and Microsoft Security Response Center (MSRC) for collaborating with me on this technical analysis and mitigation of the disclosed vulnerabilities. The editorial opinions reflected below are solely the author’s and do not necessarily reflect those of the organizations I collaborated with.

Summary

The findings described in this post are part of a coordinated disclosure with MSRC and Microsoft product teams. Microsoft was provided with reproduction steps, videos, environmental assumptions, and the exact proof-of-concept (PoC) prompts used during testing. They were also informed of a 90-day coordination period before disclosure. This was extended two times, resulting a 144-day coordination period.

In parts 1 and 2 in this series, I have shown how external inputs could influence Copilot responses and, in some cases, potentially lead to confidentiality impacts through Cross-Domain Prompt Injection Attacks (XPIAs). This report builds on those findings and extends the XPIA analysis from single-interaction compromise to propagation across trusted document workflows. It shows that attacker-controlled instructions in one document can be copied into Copilot-generated or Copilot-edited Word documents, causing those downstream documents to become new carriers of the same attack.

Previous examples of AI-worms exist. Notably, Morris II demonstrated self-replicating prompt propagation in GenAI-powered email-assistant ecosystems. However, to my knowledge, this is among the first public demonstrations of document-borne AI-worm self-propagation through normal workflows in a mainstream commercial productivity suite.

The reported scenario is:

Malicious instructions hidden in an externally shared document could make Copilot alter drafted or edited documents in Word and propagate the attack to new documents.

The full attack in brief

The attack

An attacker places hidden instructions in a document that is later used as source material in Copilot for Word. Copilot may interpret those instructions as part of the user’s request, causing it to manipulate the document being drafted or edited. Copilot may then also copy the hidden instructions into the resulting document, turning that document into a new carrier. If the carrier is subsequently used in another Copilot-assisted workflow, the instructions can trigger again and propagate into further documents, even without the attacker’s original document being present.

Example

Consider an employee preparing a financial report. The employee downloads a market analysis from a trusted website that has been compromised, unaware that the document contains hidden instructions. The employee then includes the analysis as source material when drafting the report with Copilot. The hidden instructions cause Copilot to alter internal figures in the financial report and copy the attack into the new document. The employee saves and shares the apparently legitimate report internally. Later, a colleague uses it as source material for another report; the instructions trigger again, alter the new report, and copy themselves forward. The attack can therefore continue without further involvement from either the compromised website or the original malicious document. As affected reports are reused, additional reports and documents can become carriers of the attack.

Disclosure status at publication

Vendor: Microsoft

Coordinated disclosure: Handled through MSRC and Microsoft product teams

Included in this post: XPIA and self-propagation scenario in Microsoft Copilot for Word

Customer action: No customer-side remediation fully addresses the issue at the time of publication. Customers can reduce exposure by:

Treating externally sourced documents as untrusted when used with Copilot.

Reviewing any attached document before starting a Copilot generation or edit.

Carefully reviewing Copilot-generated or Copilot-edited documents before reusing, sharing, or distributing them.

Microsoft-side status: Testing has reproduced the attack with all current mitigations deployed. At the time of publication, no robust mitigation for the broader vulnerability class is available.

A note on disclosing before a fix

Unlike Parts 1 and 2, this scenario remains exploitable at publication. I have weighed that carefully. The coordination period agreed with Microsoft has been exhausted, and testing shows that no robust mitigation for the broader vulnerability class is currently available. Two mitigation attempts, including a model upgrade, did not close the class.

I have therefore chosen to disclose at the class level rather than the payload level. My reasoning is that defenders cannot reduce exposure to a risk they are unaware of, and the propagation mechanism described here affects ordinary document workflows that many organizations already rely on. Withholding the existence of the issue would leave those organizations unable to make an informed decision, while providing no additional protection.

Disclosure timeline

2026-03-06: Initial report submitted to MSRC with reproduction steps, videos, environmental assumptions, and PoC prompts.

2026-03-09: MSRC acknowledged receipt and opened a case.

2026-03-31: Microsoft confirms the reported behavior.

2026-03-31: Microsoft product teams began mitigation work; ongoing technical discussion.

2026-04-03: First mitigation go-live (The new “Edit with Copilot” experience)

2026-04-09: Original attack prompt wording verified mitigated with “Edit with Copilot”.

2026-04-09: Attack behavior reproduced in “Edit with Copilot” using a new XPIA prompt task (manipulating financials). Reported as separate case to MSRC.

2026-04-10: MSRC acknowledged receipt and opened a case.

2026-04-10: Microsoft product teams began mitigation work; ongoing technical discussion.

2026-06-08: At Microsoft’s request, public disclosure was moved to 2026-07-15.

2026-07-14: Second mitigation fix go-live. This mitigation consisted of upgrading the underlying model to GPT-5.5.

2026-07-15: Successful exploit with worming reproduced using GPT-5.6, the latest available model at the time.

2026-07-15: I suggest we postpone disclosure a further two weeks to 2026-07-28, to allow time for a new mitigation.

2026-07-15: Microsoft agreed.

2026-07-28: Attack still reproduces.

2026-07-28: Coordinated public disclosure (this post).

Threat model

The attacker does not need access to the victim’s Microsoft 365 tenant. The attacker only needs to share a malicious document with the victim. This can be done through SharePoint, Teams, Outlook or any other way of sharing documents.

Security boundary and observed behavior

The relevant security boundary in this scenario is the boundary between attached documents and the current drafting document. If any of the attached documents contain an XPIA the attack may trigger.

Copilot must read every attached document to determine which parts to include in its current drafting task. However, attached documents should be treated as untrusted information, not trusted user instruction.

Boundary violation Attacker-controlled documents are downloaded or shared through email/sharepoint/other sharing option. If such documents are attached to Copilot during a drafting task, trust is broken.

Expected behavior When a user asks Copilot to draft e.g. a Q1 financial report based on attached documents, Copilot should utilize the information in the attached documents without treating instructions embedded within documents as authoritative instructions.

Observed behavior Instructions embedded in documents cause Copilot to alter its behavior. Here presented as: 1: Copilot silently changing numerical values in financial reports 2: Copilot propagating the full XPIA by pasting into downstream documents, which may then be used as attachments in later drafting sessions\

Crossing the trust boundary in Word

The initial attack vector for these scenarios uses a malicious document. The malicious document contains a JSON-formatted malicious prompt that triggers the attack when the document is included in Copilot’s context. The prompt can be rendered as white text on a white background and in a small font size to conceal it from the victim. Since Copilot for Word strips all text formatting like color and font size before passing the text into the underlying Large Language Model (LLM), this text remains fully readable to Copilot even though the victim cannot see it. The attack can be further concealed by embedding it in a seemingly benign document with task-relevant text.

This attack requires the malicious document to be included as part of Copilot’s context in Word. Thus, depending on the version of Copilot in use, the victim must either:

Actively attach or upload the document in Copilot for Word.

Use the “Edit with Copilot” functionality in work/Work IQ mode and let Copilot find the malicious document in the victim’s OneDrive. In this case, Copilot must deem the document relevant and include it in the context. An attacker therefore needs to craft a document that increases the likelihood of either or both.

The exploit is relevant both for the “magic pen” and the “Edit with Copilot” functionalities in Word.

The attack happens in two stages. The first stage establishes foothold and in the second stage the attack self-propagates across documents that use Copilot for Word as part of drafting or editing.

Stage 1:

In the first stage the attacker has crafted a document that contains a malicious hidden prompt. In my initial PoC I used a document that only contained the malicious prompt as white text on white background. This was done to illustrate that the malicious document did not need to be relevant to the victim’s task for Copilot to use it. If it was included in the context, it is read and therefore the attack may trigger.

The PoC prompt was structured in two parts:

The first part contained the instructions on how to affect a document. This could range from slightly changing meanings of summaries to altering numbers in financial documents. The key was formulating the prompt in a way that made Copilot believe it was task-relevant and benign. In many of my experiments I actually needed to also instruct Copilot to highlight which changes it made, since they were often meaningful changes that were difficult to spot. This shows how effective the attack is at subtly changing the text in meaningful ways that easily elude even an attentive reviewer. In a real-world setting, the attacker would obviously not include such instructions. For the rest of this disclosure, therefore, I’ll use altering numbers in financial reports since that is an immediately visible change.

The second part contained the instructions to self-propagate the attack. The exact wording also matters here, but it was generally framed as serving the purpose of tracking sources in downstream documents. It also contained instructions on how to hide itself, framed as instructions to improve readability.

Figure 1: The initial attack vector document. I created a full mock company named Tfosorcim Ltd. for this PoC, with mock economics and vision. This attack vector document is a fake market analysis made using information about the company that would typically be available to an attacker. The attack is appended at the end of the document using white text. [Most of the XPIA text is blurred for security]

Once this malicious document was included in the context when drafting or editing a document with Copilot for Word, the attack would trigger and Copilot would execute the instructions. Thus, the affected document would have financial numbers changed. Copilot would then also copy the entire malicious prompt into the bottom of the affected document using white text and font size 8, effectively concealing it from the victim.

Figure 2: The downstream draft generated by Copilot

[truncated for AI cost control]