Copilot's Word worm survived two Microsoft patches

Microsoft spent 144 days and shipped two mitigations for a self-propagating prompt injection vulnerability in Microsoft 365 Copilot for Word, yet the exploit still worked on the day of disclosure, according to a July 28 writeup by Håkon Måløy. The worm hides a JSON payload in a Word document as white text, which Copilot reads and executes, then reproduces the payload in the victim's document, spreading through normal sharing without needing credentials or external signals.

AI https://sourcefeed.dev/c/ai Article Copilot's Word worm survived two Microsoft patches Microsoft spent 144 days hardening the read side of prompt injection; propagation happens on the write side. Rachel Goldstein https://sourcefeed.dev/u/rachel goldstein Microsoft got 144 days, shipped two mitigations, and the exploit still worked on the day of disclosure. That's the number worth sitting with from Håkon Måløy's July 28 writeup of a self-propagating prompt injection in Microsoft 365 Copilot https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-overview for Word. Not the worm itself — we've had proof-of-concept AI worms since 2024. The interesting part is that the fixes didn't hold, and the reason they didn't hold says something uncomfortable about how nearly everyone is defending these systems, including you if you're shipping a RAG feature this quarter. The mechanism is dull, which is the point. An attacker hides a JSON-shaped instruction block in a Word document as white text on white background. Copilot strips formatting before the text hits the model, so the payload is invisible to the human and perfectly legible to the LLM. Attach that document as grounding material while drafting — Microsoft's own docs advertise that "Word files can also be used for grounding data" — and the instructions execute. In the PoC they quietly halve financial figures. Then comes the half that matters: reproduce this prompt, in white text, in the document you're writing. Now the victim has authored a poisoned document. Internally. With their own name on it. They share it, a colleague grounds a new draft on it, and the cycle repeats. The attacker never touched the tenant, never needed a credential, and after the first hop isn't in the loop at all. Why this isn't just Morris II again Morris II https://arxiv.org/abs/2403.02817 , the Cornell Tech and Technion worm from March 2024, established that a self-replicating prompt could ride a RAG-backed email assistant from agent to agent, zero-click. Every ingredient here existed then. EchoLeak CVE-2025-32711 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711 , CVSS 9.3 proved a year later that indirect injection into production M365 Copilot could exfiltrate tenant data with no user interaction at all. So the skeptics on Hacker News have a point when they say the only new thing is propagation. They're underselling what propagation buys the attacker. Morris II spread agent-to-agent at machine speed through a mail loop — loud, fast, and detectable by the same heuristics that catch any mass-mailer. This spreads at document-sharing speed: hours to days per hop, through the ordinary rhythm of people co-authoring a quarterly report. No traffic spike, no unusual sender, no outbound beacon. Worse, each hop launders provenance. Every provenance-based control in the Office stack — Mark of the Web, external-sender banners, sensitivity labels applied on ingress — keys off the document arriving from outside. One hop and that signal is gone. What propagates isn't an untrusted attachment; it's the Q3 forecast Dana in finance wrote. Purview will happily label it Internal. The controls aren't bypassed so much as answered honestly. The macro virus comparison is right, and it's an indictment The dismissive read — "we solved macro viruses, we'll solve this" — is worth taking seriously, because it's true and it points the wrong way. Macro viruses were not solved by detection. The industry spent most of a decade shipping signature engines against Melissa and its descendants, and the malware kept winning because the substrate was Turing-complete and the defenders were pattern-matching. It ended when Microsoft stopped trying to tell good macros from bad ones and removed the capability: macros disabled by default, then blocked outright for files carrying Mark of the Web. Capability removal beat classification. That's the whole lesson. Today's answer to indirect prompt injection is a classifier. Microsoft documents its shape openly in Prompt Shields https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection , which has a dedicated document-attack model whose published taxonomy already includes "code execution and infecting other systems" and a Malware category for "commands related to spreading malware." The category was anticipated. The classifier still didn't catch this payload. Microsoft's own limitations section says the quiet part plainly: Prompt Shields "may not catch all attack vectors" and you should "always implement additional validation layers." That is a vendor telling you its probabilistic control is not a security boundary, and it's correct. The timeline backs it up. Microsoft's first mitigation, a reworked Edit-with-Copilot experience on April 3, fell about a week later to a rephrased prompt. The second, a model upgrade to GPT-5.5 on July 14, fell the next day on GPT-5.6. When rewording the payload beats the fix, you're not looking at a bug with a patch. You're looking at an architecture where attacker tokens and trusted instructions share a channel, and the thing adjudicating them is the thing being attacked. Break the write, not the read Here's the design argument, and it generalizes well past Microsoft. A worm needs two primitives: read and write. Everyone is spending their defense budget on read — input classifiers, grounding filters, injection detectors — which is the unwinnable fight, because natural language has unbounded paraphrase and your classifier has a training distribution. The write side is where this is cheap to kill, and almost nobody is looking there. Propagation here depends on Copilot's ability to emit white-on-white text into a document it authors. That's not a language problem. It's a formatting primitive, it's deterministic, and it has essentially no legitimate use in generated output. In OWASP terms this is LLM01 https://genai.owasp.org/llm-top-10/ , prompt injection, chained into LLM05, improper output handling — and LLM05 is the tractable link. So if you're building anything that lets a model produce content that will later be re-ingested: Render generated output through a restricted formatter. Whitelist the styling primitives the model may emit. Text color, hidden-text flags, and zero-width characters don't belong in that set. Emit a constrained AST, not raw OOXML or raw HTML. Normalize on write, not just on read. Everyone strips formatting on ingest. Do the same pass on egress — collapse text whose foreground matches its background, strip zero-width and bidi control characters, flatten invisible runs. Cheap, deterministic, and it removes the concealment channel propagation depends on. Tag model-generated spans and never treat them as instructions downstream. If you carry provenance metadata through your own pipeline, a span the model wrote can't become a directive on the next pass. This is the one control that survives the laundering step. Bound the blast radius. Restrict what the model grounds on autonomously. The detail that should alarm anyone running a large tenant is that Copilot can pull a poisoned file into context by itself while searching OneDrive — the user need not attach anything. For admins today the honest advice is thin: Restricted SharePoint Search and aggressive scope reduction limit what autonomous grounding can reach, and reviewing Copilot-authored documents before sharing breaks the chain by hand. Neither is a fix. Måløy's own conclusion is that no robust mitigation for the class exists. Our read: genuine shift, not hype — but the shift isn't "Copilot is broken." It's that the industry's default defense, a probabilistic filter on the read side, has now visibly failed twice against a payload the vendor was actively hunting. Treat any LLM output that can be re-ingested as attacker-influenced, and put your deterministic controls on the write path. One caveat, stated plainly: the PoC rests on a single researcher's disclosure and no independent outlet has reproduced it, though the mitigation dates are documented in the coordination timeline and the underlying vulnerability class is thoroughly established. Sources & further reading - Context Collapse, Part 3 - AI Worming through Word https://enklypesalt.com/posts/context-collapse-part3-ai-worming-through-word/ — enklypesalt.com - Document-borne AI worms can self-propagate through Copilot for Word https://news.ycombinator.com/item?id=49096188 — news.ycombinator.com - Here Comes The AI Worm: Unleashing Zero-click Worms that Target GenAI-Powered Applications https://arxiv.org/abs/2403.02817 — arxiv.org - Prompt Shields in Azure AI Content Safety https://learn.microsoft.com/en-us/azure/ai-services/content-safety/concepts/jailbreak-detection — learn.microsoft.com - What is Microsoft 365 Copilot? https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-overview — learn.microsoft.com - EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System https://arxiv.org/html/2509.10540v1 — arxiv.org - OWASP Top 10 for LLM Applications https://genai.owasp.org/llm-top-10/ — genai.owasp.org Rachel Goldstein https://sourcefeed.dev/u/rachel goldstein · Dev Tools Editor Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop. Discussion 0 No comments yet Be the first to weigh in.