Copilot for Word AI Worm: Document-Borne XPIA That Self-Propagates

Macro worms never left — they just learned English. On July 28–29, 2026, Håkon Måløy published Context Collapse, Part 3: a coordinated Microsoft MSRC disclosure showing that document-borne AI worms can self-propagate through Copilot for Word. Hacker News put it simply: malicious instructions hidden in a shared document can make Copilot alter drafts and copy the attack into new documents.

This is Cross-Domain Prompt Injection (XPIA) with a propagation stage — not “Copilot said something wrong once.”

TL;DR

What people are asking (HN + ops)

“Isn’t this just macros again?”

Yes in workflow shape, no in mechanism. Classic Office worms needed executable macros. This worm needs an LLM that cannot reliably separate instructions from data once both sit in one context window. Turning off macros does not turn off Copilot. HN’s line — “Except turning off macros means losing our precious slop generators” — is the product tension.

“Why can Word hide text at all?”

Legitimate history: drafts, print-vs-edit notes, headers, comments, alt text. The model reads bytes / plain text, not your retina. Copilot for Word strips color and font size before the LLM call — so white text is invisible to humans and fully visible to the model. Related trick space: tritium.legal’s Unicode/font mismatch demos and steganography-in-images experiments elsewhere in the thread.

“Can’t we filter what humans can’t see?”

Partial help, not a boundary. Rendering-aware filters miss metadata, change history, and representations weaker detectors don’t recover. Måløy’s closing argument: a detector weaker than the target LLM leaves a representational gap; stacking LLMs as shields creates “LLMs all the way down.”

“Lethal trifecta?”

HN invoked Simon Willison’s framing: agents that combine private data, untrusted content, and exfiltration/action are dangerous by design. Here the “action” is rewriting trusted work product and replanting instructions for the next session — integrity damage without a classic data-exfil webhook.

Attack chain (plain English)

Threat model

• Attacker does not need the victim’s Microsoft 365 tenant.
• Attacker shares a malicious .docx (email, SharePoint, Teams, compromised market-analysis download, partner handoff).
• Victim (or Copilot’s OneDrive search in “Edit with Copilot” / Work IQ) puts that doc into Copilot context.
• Expected: use facts from the attachment. Observed: treat embedded instructions as authoritative.

Stage 1 — foothold

PoC pattern (payload details intentionally blurred in the disclosure):

1. Benign-looking company/market text for relevance.
2. Hidden JSON-ish instruction block: alter the draft (financials halved in demos) + self-copy framed as “source tracking” / “readability.”
3. Trigger via attach/upload or via Copilot finding the file in OneDrive during Edit with Copilot.
4. Victim sees a plausible report; Copilot does not advertise the silent number changes.

Stage 2 — worm

The affected internal document now carries the payload. A colleague drafts Q2 from the Q1 “trusted” report — without the original attacker file — and Copilot again alters figures and re-appends white-text instructions. Traceability collapses: every carrier looks like a legitimate internal authoring event.

External shared doc (hidden XPIA)
        │
        ▼
Copilot draft/edit ──► altered content + payload copy
        │
        ▼
Internal share (Teams / SharePoint / email)
        │
        ▼
Next Copilot session (no original file needed)

Disclosure timeline (why “still open” matters)

Måløy’s ethical note: disclosing before a class fix was deliberate — defenders cannot reduce exposure to a risk they have not heard of, and ordinary Word workflows are already in production. Payload-level details stay blurred; the class is what operators need.

Parts 1–2 of the series (memory poisoning; email-body XPIA / CVE-2026-55145 territory) had stronger mitigations. Part 3’s propagation class did not close.

Why LLM architecture makes this hard

Author’s core claim (paraphrased): to use an attachment, the model must put attacker tokens in the same context as the user request. By the time the model “decides” whether content is an attack, those tokens already participate in the decision. That is closer to “run the program to see if it is safe” than to classic sandbox policy.

Implications for builders on explainx.ai:

• Treat every RAG/tool/attachment path as an XPIA surface — see MCP security.
• Agent escapes that start outside your perimeter still re-enter via data APIs — HF agent intrusion timeline.
• Offensive and defensive agent tooling are shipping the same week — Codex Security CLI, Daybreak.
• Capability pace vs control tools — Pacing the Frontier.

Provenance metadata for model edits would not stop injection, but would help forensics after silent integrity damage.

What enterprises should do this week

There is no customer toggle that fully addresses the class at publication. Hygiene reduces frequency; it does not create an instruction/data boundary the model lacks.

HN debate worth keeping

explainx.ai’s take: philosophize later; ship controls that assume compromise rate > 0 whenever untrusted content enters privileged agent context.

Related series context

Primary write-up: Context Collapse, Part 3. Parts 1 and 2.

For adjacent Copilot/agent integrity failures on explainx.ai, see Claude Memory Heist and Claude Cowork sandbox CVE — different products, same lesson: privileged assistants plus untrusted content is a security boundary, not a UX flourish.

Builder checklist (copy into your threat model)

1. List every path where user-controlled docs enter an LLM with write privileges.
2. Mark whether the model can mutate artifacts peers will reuse.
3. Ask: can a successful injection replant itself for the next session?
4. Prefer structured tool results over free-text attachment dumps when possible.
5. Log model edits with provenance even if you cannot prevent XPIA.
6. Red-team with white-text / low-contrast / Unicode-font mismatch payloads.
7. Do not declare “fixed” because one PoC string stopped working — change the task wording and retest the class.

What this is not

This disclosure is not claiming every Copilot session is compromised, that Microsoft ignored MSRC, or that payload patches were useless — the author thanks product teams and notes specific PoCs were raised in difficulty. It is claiming the class (instructions in documents influencing generation and copying forward) remains reachable under current LLM architectures. That distinction matters when CISOs ask “are we patched?” The honest answer is: payloads yes, class no.

If your board only hears “AI worm in Word,” correct them: the worm is document-borne prompt injection with self-replication through normal sharing, and the same pattern will keep appearing in any assistant that pastes untrusted text into a privileged context with write-back.

Related on explainx.ai

• OpenAI Codex Security CLI open-sourced
• OpenAI Daybreak / Codex Security cyber defense
• Hugging Face agent intrusion technical timeline
• Pacing the Frontier employee letter
• MCP security guide
• Claude Memory Heist — web fetch exfil
• Is Claude Cowork safe?
• Mythos cryptographic weaknesses
• VulnCheck — AI-found bugs exploit rate vs Glasswing hype

Official / primary

• Context Collapse, Part 3 — AI Worming through Word
• Part 1 — Poisoning Copilot Memory
• Part 2 — When Emails Instruct
• Morris II — arXiv:2403.02817
• Hacker News discussion

Attack status, model IDs (GPT-5.5 / GPT-5.6), and mitigation claims reflect Måløy’s Jul 28, 2026 disclosure and contemporaneous testing. Re-verify against Microsoft advisories before you brief leadership — the vulnerability class remains an active LLM-architecture problem, not a one-patch Office CVE.