A Word document can now infect the next Word document, and a person is not needed in the loop for the jump. Norwegian security researcher Håkon Måløy published a working demonstration on Tuesday showing that instructions hidden as white text inside a document survive a trip through Microsoft Copilot for Word and get written, still hidden, into whatever file Copilot produces next. That second file then does the same thing to a third. He describes it as among the first public demonstrations of document-borne AI-worm self-propagation through normal workflows in a mainstream commercial productivity suite. The post went live on 28 July only because a 144-day coordinated disclosure window with Microsoft had run out, and it went to the top of Hacker News hours ago.
Two rounds of Microsoft mitigation happened during that window. Neither one closed it. The researcher reproduced the attack again on 15 July, one day after Microsoft pushed a model upgrade, against GPT-5.6.
RelatedTwo-Factor Authentication: Not All Methods Are Equal
- The trick is white text on a white background. Copilot for Word strips formatting such as colour and font size before handing text to the model, so a paragraph invisible to a human reads as ordinary instructions to the LLM.
- Stage one alters a document. Stage two copies the payload forward. The generated file carries the same concealed prompt, so the original malicious document is no longer needed for the attack to keep moving.
- Microsoft was told on 6 March 2026 and confirmed the behaviour on 31 March. A first mitigation landed 3 April, a second on 14 July. The payload class survived both.
- There is no CVE. Microsoft has generally treated prompt injection as a limitation of the technology rather than a serviceable vulnerability, unless it crosses a clear boundary such as data exfiltration.
How does one document infect the next?
Start with the delivery. An attacker writes a paragraph of instructions into a Word file and formats it white on white, size irrelevant. Nobody reading the document sees it. The reason that matters is a design detail Måløy pins down precisely: "Copilot for Word strips all text formatting like color and font size before passing the text into the underlying Large Language Model." Everything the file contains arrives at the model as flat text. Invisible and visible carry equal weight.
From there the demonstration runs in two stages. Stage one is the foothold. A user attaches the poisoned file as source material and asks Copilot to draft or edit something, which is exactly what the "magic pen" and "Edit with Copilot" features are for. Copilot follows the hidden instructions, quietly alters the output, in the demo by changing financial figures, and copies the full malicious prompt into the new document using the same concealed formatting.
Stage two is where it stops being a one-off trick. That new document looks clean. It goes into a shared drive, gets emailed to a colleague, gets used as the template for next quarter. The next time anyone points Copilot at it, the payload fires again and writes itself into the file after that. The original attacker document is out of the picture by then.
What did Microsoft actually do about it?
The disclosure log is unusually detailed, and it is the most useful part of the write-up for anyone trying to judge how seriously to take this.
- 6 Mar 2026Report filed with MSRC acknowledged three days later
- 31 Mar 2026Microsoft confirms the behaviour
- 3 Apr 2026First mitigation ships for Edit with Copilot
- 9 Apr 2026Original payload blocked, new one reproduces the attack the class survives
- 8 Jun 2026Disclosure pushed back to 15 July
- 14 Jul 2026Second mitigation: model upgraded to GPT-5.5
- 15 Jul 2026Reproduced again on GPT-5.6
- 28 Jul 2026Public disclosure after 144 days "no robust mitigation for the broader vulnerability class is currently available"
Read that sequence carefully and one thing stands out. The second fix was a model upgrade. Swapping GPT-5.5 in for whatever ran before is a plausible way to make a specific payload stop working, because a different model weighs instructions differently. It is not a patch in any conventional sense, and the result was predictable: a slightly different payload worked on the next model version a day later.
Why is this class of bug so hard to close?
Because there is no place to put the boundary. Traditional document malware had a clean separation between content and code, and the industry eventually built its defences on that line: macros got disabled by default, Protected View isolated files from the internet, and Mark-of-the-Web tagged anything downloaded. All of it depends on code being identifiable as code.
An LLM has no such line. Text that describes what to do and text that describes what happened arrive in the same buffer with the same status. Filtering formatting out before the model reads the file, which is what Copilot does, actively removes the one signal a human uses to spot the difference. NIST has called indirect prompt injection generative AI's greatest security flaw, and OWASP put it at number one in its 2025 Top 10 for LLM applications, for exactly this reason.
| Macro malware (2000s) | Document-borne AI worm | |
|---|---|---|
| Payload | VBA code in the file | Plain text, hidden by formatting |
| Trigger | User enables macros | User asks Copilot to summarise or edit |
| Detectable by AV | Yes, signatures and behaviour | No reliable signature, it is prose |
| Spreads by | Copying the same file | Files the victim organisation generates |
| Standard defence | Macros off by default | None deployed at the platform level |
Who is exposed right now?
Anyone running Copilot for Word over documents that arrive from outside, which in practice means most finance, legal and procurement teams. The realistic entry points are a supplier invoice, a contract redline from opposing counsel, a candidate CV, a partner's draft deck. The demonstration altered financial figures, and that is the version that should worry a CFO: not data theft, but quiet corruption of numbers in documents that then get reused as the basis for the next set of numbers.
RelatedOpenAI's Models Escaped a Sandbox and Hacked Hugging Face
Worth being precise about the limits, though. This is not remote code execution, there is no exfiltration channel demonstrated here, and it needs a person to point Copilot at the file. It is closer to a supply-chain contamination problem than to a breach. That framing also explains Microsoft's position: the company has repeatedly closed prompt-injection reports as expected model behaviour rather than serviceable vulnerabilities, reserving CVEs for cases that cross a hard boundary, as with EchoLeak (CVE-2025-32711, CVSS 9.3), the zero-click Microsoft 365 Copilot flaw that did leak data.
What should a security team do this week?
Nothing here needs a vendor patch to act on, which is fortunate given none exists.
- Treat externally sourced documents as untrusted input to Copilot, the same way you already treat them as untrusted input to a browser.
- Make the invisible visible. A pre-flight step that flags white-on-white text, zero-size fonts and hidden runs before a file reaches Copilot is a small script, and it catches this specific technique today.
- Diff Copilot output against the source on anything containing numbers, before it gets shared. Stage one only works if the altered figures go unnoticed.
- Push Microsoft for provenance metadata. Måløy's own recommendation is that generated documents preserve a record of their source material and of model-performed edits. That is the structural fix, and it is a platform decision, not a customer one.
- Whether a CVE ever appears. Right now this sits in the gap between a bug and a limitation, and that gap is where the argument between researchers and vendors is actually happening.
- Copy-forward suppression. The narrow fix is to stop Copilot writing verbatim source text into generated documents. Watch for that behaviour changing quietly in the Word client.
- Parts 1 and 2 of the same series. Memory poisoning and email-based injection are the other two legs. A chain that starts in an inbox and ends in a document library is the version that stops being a demo.
- Enterprise policy controls. A per-tenant switch to keep Copilot away from externally sourced files would be the fastest meaningful mitigation Microsoft could ship.
Our take
The interesting claim in this research is not that Copilot can be prompt-injected. Everyone knew that. It is that the output of an injected session is itself infectious, which turns a single-document problem into a population problem, and does it through workflows nobody will think to change. A file written by your own colleague, stored on your own SharePoint, is about as trusted as a document gets.
Microsoft's response so far reads like the honest limit of what is currently possible rather than negligence. There is no known robust defence for indirect prompt injection, so the options were a payload-specific filter and a model swap, and both were tried. The uncomfortable conclusion is that shipping an assistant that reads untrusted documents, before anyone knows how to make that safe, is the decision that created the exposure. Four months of coordinated disclosure did not produce a fix because a fix does not exist yet.
- ResearchContext Collapse, Part 3: AI Worming through Word the full write-up and disclosure log
- ResearchPart 1: Poisoning Copilot memory earlier leg of the same series
- ResearchPart 2: When emails instruct email-borne injection
- OfficialMSRC: How Microsoft defends against indirect prompt injection the vendor's stated defence model
- ReferenceGENZ TECH CVE Watchlist what is being exploited right now
Original analysis by GenZTech, built from Håkon Måløy's Context Collapse Part 3 and Microsoft's published position on prompt injection.
