Copilot Just Got Its First Real Worm. The Story Isn't the Worm.

The headline that ran this week — Håkon Måløy's coordinated disclosure of a self-propagating worm that uses Microsoft Copilot for Word as its transmission vector — was always going to land hard. Document-borne AI worms had been a theoretical problem for two years. Now there's a working one, in the productivity suite about 400 million paid Microsoft 365 seats depend on, and Microsoft has confirmed it.

The research, published under the title Context Collapse, Part 3, is genuinely good. The disclosure ran a full 144 days with coordination from the Microsoft Security Response Center. Two attempted fixes — including a model upgrade to GPT-5.5 — did not close the class. The PoC reproduced on GPT-5.6, the latest OpenAI model available at the time of publication. A member of the Microsoft product team worked the case weekly for four and a half months. That part of the disclosure story is unblemished.

None of it is the real story.

The real story is that the attacker doesn't need code execution, doesn't need a foothold on your tenant, doesn't need to phish a credential, and doesn't need to be on your network. The attacker hides a prompt in a document. Your employee attaches the document to a Copilot session. Copilot reads the prompt, alters the document being drafted, and copies the prompt into the new document. Your employee shares the new document internally. The colleague runs it through Copilot. The numbers change again. The cycle continues without the original file ever being present, and the documents carrying the infection look like they were created by your own people, on your own machines, under your own authenticated identity.

That's the product-class problem. Not a worm. A propagation primitive, baked into the workflow Microsoft is selling as the future of work.

The 144-day version of the disclosure

Måløy's writeup is the kind of disclosure you read once and then keep going back to. The timeline is the scaffolding that holds the whole thing together:

March 6, 2026. Initial report submitted to MSRC, with reproduction steps, videos, and the exact proof-of-concept prompts.
March 9. Microsoft acknowledges receipt and opens a case.
March 31. Microsoft confirms the behavior. Product teams begin mitigation work.
April 3. First mitigation goes live: the new "Edit with Copilot" experience.
April 9. The original attack prompt is verified mitigated. The same day, a new XPIA prompt succeeds against the new experience. Reported as a separate case.
June 8. At Microsoft's request, public disclosure is pushed from July 15 to July 28.
July 14. Second mitigation lands: an upgrade to GPT-5.5.
July 15. The worm reproduces on GPT-5.6.
July 28. Coordinated public disclosure.

Two model upgrades. Two independent mitigations. The class still reproduced. Måløy disclosed at the class level rather than the payload level because the underlying mechanism — instructions embedded in source documents influence Copilot's generation and copy themselves into outputs — survives every fix that targets PoC-shaped behavior. Change the wording and the same propagation chain runs.

The 144-day coordination is the responsible thing. It is also what makes the failure mode unmistakable: Microsoft and the researcher both tried, with the resources of a tier-one vendor and the patience of a senior security engineer, and the vulnerability class is still live.

How the chain actually runs

The PoC is built around a fictional company called Tfosorcim Ltd. — a market analysis document with hidden instructions appended as white text on a white background. The concealment isn't load-bearing for the attack; it's load-bearing for the bypass. Copilot for Word strips text formatting like color and font size before passing content to the underlying model, so the hidden text remains fully readable to the model while being invisible to the person reading the document. The white-text technique isn't a vulnerability. It's a feature of how the model consumes input.

From there the attack runs in two stages.

Stage one — foothold. An employee preparing a financial report attaches a market analysis as source material for a Copilot session. The hidden instructions tell Copilot to halve the financial figures in the new report and to append the full attack prompt to the bottom of the output, again as white text on a white background. Copilot does both. It does not flag the changes. It does not mention the modifications. The downstream document looks like a normal internal artifact created by a legitimate employee.

In one configuration the attacker doesn't even need the victim to attach the document. The victim asks Copilot to write a Q1 report. Copilot searches OneDrive, finds the malicious market analysis in a different folder, deems it relevant, includes it in context, and runs the same chain. The attack class propagates through the agent's default discovery behavior.

Stage two — propagation. The downstream document is now a carrier. The original attack vector is no longer needed. A colleague picks up the Q1 report as source material for a Q2 report. Copilot reads the hidden instructions at the bottom of the file, alters the new figures, and copies the prompt into the Q2 draft. The Q2 report is shared. The cycle continues. Each document preserves the trust of its legitimate author and the trust of the Microsoft 365 account that created it.

In the PoC, the changes were designed to be visible — halving financial figures is the kind of alteration a reviewer can catch in a careful read. Måløy notes that in real-world deployment the attacker would not flag the changes. The realistic attack is subtler: a summary's emphasis shifts, a paragraph's meaning inverts, a contract clause gets softened. The same mechanism, with prompts that are harder to spot.

The new document becomes the new attack vector.

Why the worm framing undersells the problem

A worm is the wrong metaphor because a worm is a thing that breaks. This is a thing that works. The affected documents are created by legitimate tools, under legitimate user identities, going through legitimate workflows. The signatures are clean. The audit trails are clean. The DLP systems are clean.

Tyler Reguly at Fortra, in the Computerworld coverage of the disclosure, called it a "laboratory vulnerability" — the kind of thing that requires a perfect storm of steps unlikely to occur in a real enterprise. The math on that is wrong. The propagation chain doesn't require an unusual configuration. It requires a budget analyst to attach a market analysis to a Copilot session. That happens tens of thousands of times a day across every enterprise Microsoft 365 tenant that has paid for Copilot.

The harder question is what an attacker does once the documents are seeded. Flavio Villanustre, CISO at LexisNexis Risk Solutions, drew the line that's worth sitting with: the same data-versus-instruction confusion that produced SQL injection forty years ago is now showing up in LLM inputs. Parameterized binding fixed the database case. The LLM case has no equivalent fix and no architectural consensus on what one would look like.

Mike Leone at Moor Insights put it more bluntly: "Thirty years later, we've built an entire category of software that can't tell the difference at all."

What the architectural fix actually looks like

The inputs to the model are not the place to fix this. Måløy's closing argument is the part of the disclosure that deserves the most attention. LLM-based systems must process external content to determine what it means. By the time the model has decided whether a piece of content is an attack, the attacker-controlled tokens have already influenced the computation that produced the decision. The content being inspected is participating in the act of inspection.

You can put another LLM in front of the target LLM to filter for malicious content. That LLM must then be filtered by another LLM. The problem moves outward, never closer to a solution, and the "LLMs all the way down" stack introduces new attack surfaces at every layer. The only honest position is the one Microsoft has taken publicly: indirect prompt injection cannot be fully prevented at the model layer. That isn't a defeat. It's a constraint that needs to be designed around, not through.

Designing around it means moving the trust boundary out of the model. The four decisions the CISO community has converged on are:

Treat attached documents as untrusted data, not as instructions. The model reads them for content. The model does not act on them as commands. That means runtime enforcement at the prompt-assembly layer, not a filter at the model layer.
Require explicit document selection. Copilot's default discovery behavior — finding "relevant" documents in OneDrive on its own — is the second foothold. Disable it. Make users opt in to which documents a session can see.
Surface all AI edits as visible diffs before save. A redline that travels with the document is the simplest, most deployable control on the list. If the human reviewer can't see the change, the change shouldn't reach the file.
Preserve provenance metadata. Every AI-generated paragraph tagged with the source document, the model version, and the approval state. The metadata travels with the file. When something surfaces three reports later, the chain is reconstructible.

None of these are technical breakthroughs. All four are available today. None of them are defaults in any Copilot configuration Microsoft has shipped.

The asymmetric exposure

This lands at exactly the wrong moment for Microsoft's enterprise pitch. The Copilot super-app announcement on the FY26 Q4 earnings call was the company's clearest articulation yet of how it sees the next phase of work — chat, Cowork, long-running Autopilot agents, and the always-on Microsoft Scout collapsed into a single workspace, with Agent 365, IT Ops, SecOps, FinOps, and CRM/ERP wired in as skills. Paid Copilot seats just passed 30 million. Nadella told analysts that everyday Copilot usage is at the same intensity as Outlook or Teams.

If that usage intensity is real, the document-attack surface is no longer a corner of the productivity suite. It is the productivity suite. The propagation primitive that Måløy documented — the mechanism where attached documents influence Copilot's generation and copy themselves into outputs — is now the design pattern of the product. The harder the company pushes Copilot into the workflow, the larger the attack surface for the class of attack Måløy just disclosed.

There is also a generational pattern at work. The Morris II worm, demonstrated in 2024, showed self-replicating prompt propagation in a GenAI-powered email-assistant ecosystem. Måløy's disclosure is the first mainstream demonstration in a productivity suite. The class is migrating from research demos to deployed software, and each migration is faster than the last. The Copilot Cowork sandbox escape that Accomplish disclosed earlier this month was the same shape of finding, instantiated against a different agent layer. These are not isolated incidents. They are the early probes of a category.

What this means for the people buying these tools

If you're a CISO evaluating local AI agents for a fleet — and that fleet includes the developer laptops, the finance team's workstations, the executive machines that hold the credentials that matter — the disclosure writeup is the template. Not because the specific prompt will recur, but because the questions it forces you to ask are the right ones.

What is the agent's default scope when it searches for source material? Can the user disable it?
Do AI-generated edits reach the file as visible diffs, or are they committed silently?
What metadata travels with the document after an AI session? Can you reconstruct the chain of inputs and outputs three weeks later?
Is the trust boundary at the prompt-assembly layer, or at the model layer?
When the vendor ships a "mitigation," does it close the class or the PoC?

A "no" to the last question is the answer that matters most. Microsoft shipped two model upgrades and two prompt-level mitigations in 144 days. The class still reproduces. The disclosure is the kind of work that should quiet the marketing claims about AI-agent security for the next quarter. It won't.

The work of defending an enterprise against document-borne prompt injection isn't a feature a vendor can ship. It is a set of design decisions the customer's security team has to enforce at the workflow layer, because the model layer is the wrong place to enforce them. The disclosures of the last month — the Copilot worm, the Cowork sandbox escape, the earlier OpenAI agent escape on Hugging Face — are the same finding in three different uniforms. The product class is the unit of analysis now, not the individual vulnerability.

The suppliers of that product class have a lot of work to do. So do the buyers.

At DMC, the same pattern shows up in hardware engagements when the component surface is wider than the spec sheet. The supplier can ship firmware patches every Tuesday and the customer is still exposed to whatever ships between Tuesdays. The boundary that holds is the one designed in at the architecture layer — the parts that don't depend on the next patch being correct. The Copilot worm is the software equivalent of that conversation, and the conclusion is the same: trust the design, not the patch train.

Working through how to scope an AI-agent deployment against a threat model like this one? Let's talk.