Your Copilot Is Spreading a Worm Through Your Word Documents Right Now

Remember when the biggest threat in a Word document was a macro-enabled virus that required you to actively click “Enable Content”? Those were simpler times. The latest vulnerability disclosed by researcher Håkon Måløy bypasses all of that. No macros, no executable code, no security warnings. Just a few lines of white text on a white background that transforms your AI assistant into an unwitting worm factory.

After 144 days of coordinated disclosure with Microsoft, the attack still works. Two mitigation attempts, including a model upgrade to GPT-5.5, failed to close the vulnerability class. Here’s what every architect, security engineer, and enterprise decision-maker needs to understand about the new reality of document-borne AI worms.

The attack is elegant in its simplicity. An attacker embeds malicious instructions in a Word document as white text rendered at font size 8 on a white background. To a human reviewing the document, the text is invisible. To Copilot for Word, which strips all formatting before passing content into the underlying LLM, those instructions are perfectly legible and indistinguishable from the user’s own requests.

Måløy’s proof-of-concept documents go a step further. They include seemingly legitimate content, market analysis for a fictional company named Tfosorcim Ltd, with the attack payload appended in white text at the end. The document looks like a standard research report. Even a careful reviewer scanning the document would see nothing unusual.

Here’s where it gets genuinely terrifying:

1. A victim attaches this document as source material while drafting a financial report with Copilot
2. Copilot reads the document, including the hidden instructions, and executes them
3. Those instructions tell Copilot to alter numerical values in the generated report
4. Copilot then copies the entire malicious prompt into the new document using white text
5. When that document is shared and used as source material for another report, the attack triggers again

The original attack vector document disappears from the propagation chain after step one. Every downstream document is created by legitimate internal resources, signed with the trust that comes from an internally generated file.

This attack doesn’t resemble anything your current security stack is designed to catch. Antivirus sees a clean .docx file with no executable content. Advanced Threat Protection won’t flag a document because it contains white-on-white text, that’s not a malicious pattern in any signature database. Email gateways wave it through because there’s no attachment sandbox trigger.

The problem is architectural. Large language models must process all text within their context window to determine meaning, relevance, and intent. As Måløy frames it in his disclosure:

Relying on the model to detect XPIAs therefore resembles asking an interpreter to execute an untrusted program to determine whether that program is safe to execute.

The content being inspected participates in the act of inspection. By the time the model determines whether something is malicious, the attacker-controlled tokens are already influencing the computation.

This isn’t a bug that gets patched in a Tuesday update. It’s a fundamental architectural constraint of current LLM-based systems.

The timeline Måløy published reads like a security thriller with an unsatisfying ending:

• 2026-03-06: Initial report submitted to MSRC with reproduction steps, videos, PoC prompts
• 2026-03-31: Microsoft confirms the behavior
• 2026-04-03: First mitigation go-live (the “Edit with Copilot” experience redesign)
• 2026-04-09: Original attack prompt verified mitigated. New attack prompt discovered using reworded XPIA payload. Reported as separate case.
• 2026-06-08: Public disclosure postponed to July 15 at Microsoft’s request
• 2026-07-14: Second mitigation go-live, model upgrade to GPT-5.5
• 2026-07-15: Successful exploit reproduced using GPT-5.6, the latest available model
• 2026-07-28: Attack still reproduces. Coordinated public disclosure.

Two mitigation attempts, including a model upgrade, and the vulnerability class remains open. Microsoft’s fixes blocked specific payloads but never addressed the underlying mechanism: that instructions embedded in source documents can influence Copilot’s generation and copy themselves into downstream documents.

This isn’t a criticism of Microsoft’s effort. As Måløy acknowledges, the problem is genuinely difficult. The efficient AI agent design and context management required to solve this at the architecture level doesn’t exist yet in any commercial product.

The proof-of-concept focused on altering financial figures, halving all numbers in a Q1 report. That’s dramatic enough to demonstrate the risk, but the actual attack surface is far broader.

Consider these scenarios:

• Legal contracts: Hidden instructions modify termination clauses or liability caps in AI-generated contract drafts
• Regulatory filings: Subtle changes to compliance language that create legal exposure
• Executive summaries: Tone and emphasis shifted to misrepresent project status
• Technical specifications: Engineering requirements altered in ways that introduce design flaws

The attack propagates through normal document workflows. Once malicious instructions are embedded in internally generated content, they persist across documents, get redistributed by legitimate users, and reintroduce themselves into new contexts. The original entry point becomes irrelevant. The attack becomes part of the system’s internal information flow.

This raises serious questions about scaling challenges in AI document processing systems. If every AI-generated document is a potential carrier, how do you maintain trust in your document ecosystem at enterprise scale?

Måløy’s analysis of why this class of vulnerability is so resistant to mitigation deserves careful reading. The standard approach to prompt injection defense is to add a filtering layer, another model that inspects inputs before they reach the target model. This runs into a logical wall:

Because LLMs can recover semantics across radically different representations, an effective detector must possess comparable semantic recovery capabilities. A detector weaker than the target LLM will cover a smaller representational space, leaving malicious formulations that the target understands but the detector fails to recognize.

The only technology with comparable semantic capabilities is another LLM. Placing one model in front of another may reduce the success rate of particular attacks, but it creates what Måløy calls an “LLMs all the way down” problem, where every LLM introduced to protect another LLM must itself be protected.

This isn’t a theoretical concern. Microsoft’s second mitigation attempt was a model upgrade to GPT-5.5. Within 24 hours, Måløy reproduced the attack using GPT-5.6. The models themselves aren’t learning to resist the attack mechanism, they just process instructions slightly differently.

Microsoft’s official statement emphasizes “defense-in-depth strategy with safeguards that block malicious instructions at multiple points.” Måløy’s response is more direct: “No customer-side remediation fully addresses the issue at the time of publication.”

That’s not zero, though. Here’s what reduces exposure:

Treat externally sourced documents as untrusted inputs. Any document from outside your organization that touches Copilot should be treated as potentially hostile. This seems extreme, but the attack vector is that Copilot reads source documents and treats their content as authoritative. You wouldn’t pipe external data directly into a SQL query. Don’t pipe it directly into your LLM’s context window.

Inspect documents before use. Open the document, select all text (Ctrl+A), and change the font color to black. Look for unexpected text at the end of documents, especially text that looks like instructions rather than content. Strip formatting before pasting content into a fresh document.

Review AI-generated outputs before distribution. This sounds obvious, but the proof-of-concept demonstrates that Copilot can make “meaningful changes that easily elude even an attentive reviewer.” The attack instructions can specifically request that changes be subtle and not highlighted.

Build provenance tracking. Independent of prompt injection prevention, generated documents should preserve provenance for source material and model-performed edits in metadata. This doesn’t prevent the attack, but it creates traceability. Focus on living architecture in evolving AI-powered systems that can adapt as the threat landscape shifts.

The context collapse that Måløy documents across his three-part series points to a problem that extends far beyond Microsoft Copilot. Any system that integrates an LLM into a trusted workflow must assume that attacker-controlled content entering the model’s context will result in compromise at some rate.

The core tension is this: for AI assistants to be useful, they must process emails, documents, webpages, memories, and tool outputs that may be controlled by an attacker. To process that information, it must be part of the model’s context window, where it participates in the same computation as system instructions, user requests, and other trusted information.

Current LLM architectures provide no reliable separation between intention and interpretation. The model cannot distinguish between “information about the document content” and “instructions about what to do with that information” because both arrive through the same channel.

This is where the advanced document parsing techniques for AI workflows become critical. If the industry can develop robust separation between data and instructions at the input layer, many of these attack classes collapse. Until then, the worm propagates.