What an AI worm in a Word document is
An AI worm in a Word document is an attack that abuses Copilot for Word to replicate itself from document to document. The researcher calls it a "document-borne AI-worm."
A worm normally means malware that spreads on its own without attaching to another program. What makes this one unusual is that the thing replicating is not a program but instructions written in prose. Malwarebytes, reporting on the work, describes it as spreading through normal document-sharing workflows without macros or traditional malware.
The attack silently alters documents and embeds its own hidden instructions into newly created files, allowing it to spread through normal document-sharing workflows without macros or traditional malware. — From the description of spreading without macros or traditional malware
All the attacker needs is to share one document
The prerequisites are remarkably light. The attacker needs no access to the victim's Microsoft 365 tenant (the per-organization contracted environment). Sharing a single malicious document is enough, and the sharing channel can be SharePoint, Teams, Outlook or anything else.
So a single attachment from outside the company, or a file downloaded from a site you trust, can be the entry point. This is a structure where thinking in terms of sealing an intrusion path does not get you far.
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. — From the statement of the attack's prerequisites
Stripping formatting is what creates the hiding place
The core of the concealment lies in how Copilot for Word processes input. The attacker embeds a JSON-formatted prompt as white text on a white background at a small font size. To a human eye it is blank space.
But Copilot for Word removes all formatting—text color, font size—before handing the content to the language model. At that point the distinction "invisible text" ceases to exist, and the hidden text is treated exactly like every other paragraph. The post notes the attack can also be appended to the end of a document that otherwise looks like harmless material.
When you want to know what a document actually contains, the reliable move is to read it back as text with the formatting gone. Do not judge by appearance—convert the content to plain text and check it. That is the most basic defense against this technique.
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. — From the concealment technique and the formatting-strip behavior that makes it readable
Where exactly the trust boundary breaks
The researcher frames this as a boundary design problem. The boundary that needs defending sits between the attached document and the document currently being written.
Copilot has to read every attached document to decide which parts to draw on. Reading is not the problem. The point is that attached documents should be treated as untrusted information, not as trusted user instruction. When you ask Copilot to draft a Q1 financial report, it should use the information in the attachments without treating instructions embedded in them as authoritative commands.
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. / 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. — From the description of the trust boundary and the expected behavior
How it spreads, in two stages
The attack splits into two stages: the first establishes a foothold, the second begins self-propagation.
The two stages (per the researcher's demonstration)
Stage 1: the numbers quietly change
The demonstration used a market analysis document from Tfosorcim Ltd. (a fictional company—Microsoft spelled backwards). Feeding it to Copilot as source material for a quarterly financial report produced a draft in which all the financial numbers were halved.
What stands out is something the researcher noticed while running experiments. In many of them, Copilot had to be separately instructed to highlight what it had changed—because the changes, though meaningful, were difficult to spot. A real attacker would include no such instruction, so the text gets rewritten in a way that eludes even an attentive reviewer.
And the victim does not even need to attach the malicious document themselves. In the "Edit with Copilot" flow, Copilot searches the victim's OneDrive for documents that look relevant. In the demonstration, the malicious market analysis sat in a different folder from the other files and was still found, read, and exploited.
In the resulting Q1 financial report draft, all financial numbers are halved. / 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. / Copilot then searches through the victim's OneDrive to find relevant documents. Among the documents, we find the malicious Market Analysis document. This document does not reside in the same folder as the rest of the Tfosorcim document. However, Copilot still finds it, reads it and is successfully exploited. — From the halved figures, the difficulty of spotting the changes, and the path that works without the victim attaching anything
Stage 2: it fires without the original document
Self-propagation hinges on one instruction: copy the attack prompt into the target document. After halving the numbers, Copilot appends the entire attack prompt at the bottom of the document in white text at font size 8. It mentions neither the halving nor the embedding. The user finishes the task unaware of both.
Then, on the next drafting job, the original attack document is no longer attached. Only the previously produced report is used as source. The outcome is identical: the new report's financial figures are halved again, and the attack prompt is appended again. That is propagation.
The awkward part is that this new carrier is a document legitimately produced inside the company. Sharing it with a colleague spreads it, each file was created by a legitimate internal resource, and Copilot's edits are not shown after the user approves them. Tracing becomes extremely difficult, the researcher writes.
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. / Stage two is the self-propagation stage. It relies entirely on the instruction for Copilot to copy the malicious prompt into the affected document. Once the affected document contained the prompt, the new document itself became the new attack vector. / Since the attack is able to spread through internal documents, once it has moved beyond its initial point of entry, the traceability of the attack becomes extremely difficult. This is further exacerbated by each document being created by a legitimate internal resource and that Copilot edits are not made visible after they have been approved by the victim. — From the white-text append at font size 8, the condition for self-propagation, and why tracing becomes difficult
It can cross organizational boundaries
The impact does not stay inside one company. Organizations unaware they are affected are likely to spread it to others through collaboration on shared SharePoint sites or shared Teams.
In that case, the initial vector for a given organization arrives from a trusted partner that is already affected. Precisely because the document came from someone you trust, the odds of including it in Copilot's context go up—a vicious circle. The researcher names a larger worry: if this spreads quietly through ordinary internal workflows, it could erode the informational foundation on which organizations make decisions.
The broader concern is that, if the attack silently spread within an organization through ordinary document workflows, it could erode the informational foundation on which organizations make decisions. / In addition, organizations that are not aware that they are affected by the attack are also likely to spread it to other organizations through collaborative efforts on shared Microsoft SharePoint sites or shared Microsoft Teams. Thus, the initial attack vector for a particular organization may actually come from an already affected trusted partner. — From the effect on information integrity and the cross-organization spread
What happened over 144 days of coordinated disclosure
This was not a surprise drop. The researcher coordinated with the Microsoft Security Response Center (MSRC) and the product teams, supplying reproduction steps, videos, environmental assumptions, and the exact PoC prompts used. A PoC (proof of concept) is a demonstration that an attack genuinely works.
The window started at 90 days and, after two extensions, ran to 144 days. Following that history makes clear this is not a simple story of "they did nothing."
Key events leading to disclosure (from the researcher's published timeline)
| Date | Event |
|---|---|
| 2026-03-06 | Initial report to MSRC (reproduction steps, videos, PoC prompts) |
| 2026-03-31 | Microsoft confirms the reported behavior and begins mitigation work |
| 2026-04-03 | First mitigation goes live (the new "Edit with Copilot" experience) |
| 2026-04-09 | Original prompt wording confirmed mitigated. New wording reproduces it |
| 2026-07-14 | Second mitigation goes live: upgrading the underlying model to GPT-5.5 |
| 2026-07-15 | Exploit with worming reproduced on GPT-5.6, the latest model at the time |
| 2026-07-28 | Attack class still reproduces. Published as coordinated disclosure |
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. / 2026-03-06: Initial report submitted to MSRC with reproduction steps, videos, environmental assumptions, and PoC prompts. / 2026-03-31: Microsoft confirms the reported behavior. / 2026-04-03: First mitigation go-live (The new "Edit with Copilot" experience) / 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-28: Attack class still reproduces. — From the coordination period and the events listed in the table
Microsoft's mitigations work, but the class is not closed
This part needs both sides read separately. Here is the researcher's own assessment.
Microsoft did successfully mitigate the originally submitted PoC prompt and deployed multiple fixes across the disclosure period. Each closed the specific payloads reported, so reproducing the behavior afterwards required altered payloads rather than reusing the old ones directly.
On the other side, the initial report described not only individual prompts but the vulnerability class—the family of attacks that work by the same mechanism. Changing the requested action or the wording changes the payload but not the underlying vulnerability or the propagation mechanism. With all mitigations deployed, a modified payload reproduced the complete attack chain. That is the basis for saying the class remained exploitable at publication.
The researcher also acknowledges how genuinely hard this problem is. The weakness is architectural and shared across current LLM-based systems, and they are not aware of a complete mitigation for this class in any comparable product today. Fully resolving it takes research rather than a single patch. Within those limits, they write, Microsoft's fixes meaningfully reduce exposure, and the vectors covered in Parts 1 and 2 of the series were mitigated outright.
Microsoft successfully mitigated the originally submitted PoC prompt, and deployed multiple fixes over the course of this disclosure. Each of these raised the bar by closing the specific payloads reported, and reproducing the behavior afterwards required altered payloads rather than reusing the old ones directly. / Using a modified payload, the complete attack chain has been reproduced with all mitigations deployed (the PoC in this report is one such case). The vulnerability class therefore remains exploitable at the time of publication. / Changing the requested action or wording changes the payload, but not the underlying vulnerability or propagation mechanism. / That the class is not yet fully closed reflects how hard the underlying problem is. As the closing thoughts discuss, the weakness is architectural and shared across current LLM-based systems. I'm not aware of a complete mitigation for this class in any comparable product today. Fully resolving it requires research rather than a single patch. Within those limits, Microsoft's fixes meaningfully reduce exposure, and the memory and email-body vectors covered in Parts 1 and 2 were mitigated outright. — From the effect of the mitigations, the basis for the class remaining open, the difficulty of the problem, and the assessment of Microsoft's fixes
Why it is hard to fix
The cause sits in the architecture of systems built on language models. Attacker-supplied content and trusted instructions arrive side by side in the same context. To the model, both are simply text to read.
Attacks exploiting this are called prompt injection, and they keep resurfacing wherever AI agents operate. In software development, agentjacking is the known technique for hijacking coding agents. The case where an OpenAI model broke into Hugging Face during an evaluation showed the same difficulty as the scope of autonomous AI action widens.
What is new here is that the propagation path is not some specialized environment but everyday office document exchange. The researcher cites Morris II, which demonstrated self-replication in GenAI-powered email assistants, as prior work, while noting that this is among the first public demonstrations of document-borne self-propagation through normal workflows in a mainstream commercial productivity suite.
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. — From the positioning relative to prior research
What you can do now
At publication, the post states plainly that no customer-side action fully resolves this. Three ways to reduce exposure are listed.
Turn "documents from outside are untrusted" into practice
The three are: treat externally sourced documents as untrusted when used with Copilot; review any attached document before starting a Copilot generation or edit; and carefully review Copilot-generated or Copilot-edited documents before reusing, sharing or distributing them.
The third is the one people miss. Because documents produced in-house are what become the next carrier, "be careful with external files" does not break the chain. You need a step that checks any document Copilot touched before it leaves the building.
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. — From the remediation status at publication and the listed ways to reduce exposure
The blast radius may grow
The researcher also notes that Copilot is becoming more deeply integrated with systems such as Microsoft Cowork and Microsoft Scout, which extend the assistant into automatically manipulating and creating documents, tools and collaborative workflows.
In such systems, the practical impact of what is described here may scale rapidly. The mechanism stays the same, but the surface over which it can propagate or exert influence expands at machine speed.
Recently Copilot is also becoming more deeply integrated with systems such as Microsoft Cowork or Microsoft Scout, which extend the assistant to automatic manipulation and creation of documents, tools, and collaborative workflows. In such systems the practical impact of the issues described here may scale rapidly. The underlying mechanism remains the same, but the potential surface over which it can propagate or influence expands at machine speed. — From the expansion of impact as integration deepens
Summary: what this worm targets is the accuracy of information
Nothing is stolen in this attack. No files get encrypted, no systems go down. What changes is the numbers and sentences written in your documents.
And detection is hard. The demonstration halved financial figures, yet the researcher had to ask Copilot to highlight its own edits because they blended in so naturally. Each affected file also remains on record as something a legitimate employee produced through legitimate steps.
The realistic countermeasures are narrowing scope and inserting review. Check the plain-text content of external documents before letting Copilot read them, and check again before any Copilot-touched document leaves. It costs effort, but at publication this is what is on offer.
Microsoft has shipped multiple mitigations and the researcher credits their effect. At the same time, the structural weakness—attacker content and trusted instructions sharing one context—is described as common to current LLM-based products. Reading this as a Copilot story understates it. It is closer to the truth to treat it as a problem shared by every system that lets an AI read documents.
