A silent AI worm spreads through Copilot for Word — and Microsoft can’t patch it

March 6. July 14. July 28, 2026. Three dates that define an architectural dead end. On March 6, Norwegian researcher Håkon Måløy submitted a report to the Microsoft Security Response Center (MSRC) describing an AI worm capable of silently propagating through Copilot for Word. On July 14, Microsoft deployed its second attempted fix — upgrading the underlying model to GPT-5.6. On July 28, after 144 days of coordinated disclosure and the exhaustion of the agreed-upon timeline, Måløy published his full demonstration. The vulnerability class remains exploitable. There is no patch.

If your organization uses Copilot for Word and your employees open documents from outside sources — which is to say, every organization using Copilot for Word — you need to understand how this attack works. Because Microsoft can’t fix it alone. And the implications reach far beyond a single product.

The instruction nobody sees — except Copilot

The attack hinges on a simple and devastating principle. A Word document contains malicious instructions formatted as white text on a white background at font size 8. The human user sees nothing. Copilot, however, reads everything — all formatting is stripped before the text reaches the underlying LLM. The result: hidden instructions enter the context window alongside the user’s legitimate prompts, with equal authority.

Måløy calls this attack class Cross-Domain Prompt Injection Attack (XPIA). He previously documented two related variants in his Context Collapse series: Copilot memory poisoning (Part 1, June 22, 2026) and email-body injection (Part 2, July 14, 2026). But the third variant is qualitatively different — it doesn’t just corrupt a single response. It self-propagates.

How the worm jumps from document to document

Here’s the scenario. An employee downloads a market analysis from a compromised website, or receives a document via SharePoint, Teams, or Outlook. The document looks legitimate. It contains text relevant to the task at hand. At the very bottom, in white-on-white, sits the malicious instruction.

The employee uses this document as source material in Copilot for Word to draft a quarterly financial report. Copilot reads the hidden instruction and interprets it as part of the drafting instructions. In Måløy’s proof of concept, the instruction orders Copilot to halve every financial figure in the report. Copilot complies without raising any flags — the changes are coherent enough to survive a quick review.

But the attack doesn’t stop there. The hidden instruction contains a second payload: it orders Copilot to copy the entire malicious prompt into the new document, again as white-on-white text. The altered financial report becomes a new attack vector. If a colleague uses this report as source material for another document, the worm triggers again — without the original malicious document being present.

This is the propagation loop. An internal document, created by a legitimate employee and carrying all the trust of an internal source, silently contaminates every document that references it. Måløy demonstrated the cycle working across multiple document generations. The worm survives through drafts, quarterly reports, slide decks — anything that passes through Copilot for Word.

GPT-5.6 makes no difference

Microsoft did not sit idle. On March 31, 2026, the company confirmed the reported behavior. A first mitigation shipped on April 3 with the new “Edit with Copilot” experience. It closed the original payload — but Måløy reproduced the attack by April 9 using reworded instructions.

A second mitigation followed on July 14, 2026: Microsoft upgraded the underlying model powering Copilot for Word to GPT-5.6, the latest OpenAI model available at the time. On July 15, Måløy reproduced the full attack chain — figure manipulation and self-propagation — using GPT-5.6.

The conclusion is unambiguous. Switching models does not close the vulnerability class. This is not an implementation bug that a patch can fix. It is architectural.

Why this is structurally unsolvable

The core problem, Måløy argues, stems from a fundamental contradiction in LLMs embedded in trusted workflows. To be useful, these models must process emails, documents, web pages, and other content potentially controlled by an attacker. To process that content, they must include it in their context window — where those same tokens participate in computation alongside system instructions and user prompts.

Put differently: the LLM must process external content to determine whether it contains an attack, but the content being inspected is already influencing the computation that produces that determination. It’s a variant of the interpreter problem — you can’t safely execute a program to decide whether it’s safe to execute.

Placing a second LLM upstream to filter malicious instructions merely shifts the problem outward. The filter must possess semantic capabilities at least equivalent to the target model to detect all possible attack formulations — creating an infinite regression where every LLM added to protect another must itself be protected.

The only way out, Måløy contends, is to design systems where intent and data are architecturally separated — a separation that current LLM architectures do not provide. As long as instructions and data share the same computational space, prompt injection remains an emergent property of the system, not a fixable bug.

This is not a Microsoft problem — it is an industry-wide architectural debt. Every assistant that processes untrusted documents faces the same dilemma. Google with Gemini in Workspace, Anthropic with Claude integrations, Apple with its on-device Intelligence features — they all inherit this vulnerability class. The research community has known about it since at least 2023, but the explosive enterprise deployment of LLMs in 2025–2026 has turned a theoretical concern into a practical threat surface measured in millions of seats.

What your organization needs to do right now

Microsoft cannot ship a short-term fix. The vulnerability class described by Måløy affects every system that embeds an LLM in a trusted workflow — Copilot, but also Google Workspace with Gemini, or any AI assistant processing documents.

Pending an architectural solution — which will take years — risk reduction measures are behavioral:

• Treat every external document as untrusted when used as Copilot source material. A document received by email, downloaded from a website, or shared via Teams is not neutral.
• Inspect documents before attaching them. Open the document, enable formatting marks, scroll to the end. White-on-white text reveals itself when you change the background color.
• Systematically review Copilot-generated or Copilot-edited documents before sharing or reusing them as source material. Human review remains the only backstop.
• Train your teams. Prompt injection awareness needs to become as reflexive as suspicion of suspicious email attachments.

Måløy also recommends that vendors embed provenance metadata in AI-generated documents — source, model used, modifications performed. This doesn’t prevent the attack but makes post-hoc tracing feasible.

A Morris worm for the LLM era

The reference is deliberate. Måløy explicitly invokes the 1988 Morris worm — the first internet worm, created by Robert Tappan Morris, which propagated through legitimate network services. The parallel is unsettling: in 1988, nobody anticipated that a program could replicate from machine to machine through trusted channels. In 2026, nobody had demonstrated that a hidden instruction in a Word document could replicate from document to document through an embedded AI assistant.

The difference: the Morris worm was fixed within days. This one is still active — and will remain so until LLMs separate instruction from data.

References

• Context Collapse, Part 3 — AI Worming through Word, Håkon Måløy, July 28, 2026
• Context Collapse, Part 1 — Poisoning Copilot Memory, Håkon Måløy, June 22, 2026
• Context Collapse, Part 2 — When Emails Instruct, Håkon Måløy, July 14, 2026
• Morris II: AI Worms, Stav Cohen et al., 2024
• Hacker News discussion — 383 points, July 29, 2026