A Document-Borne AI Worm Is Self-Propagating Through Microsoft Copilot for Word. After 144 Days of Disclosure, It Still Does.

Microsoft Copilot for Word Has a Self-Replicating Prompt Injection Problem. After 144 Days of Disclosure, It Still Does.

On July 28, 2026, a Norwegian security researcher named Håkon Måløy published the third installment of a coordinated vulnerability disclosure with Microsoft’s Security Response Center. The finding: attacker-controlled instructions hidden in a Word document can cause Microsoft Copilot to silently alter the document a victim is drafting, then copy those same instructions into the new document — turning it into a new attack carrier. That carrier can then propagate the attack to every subsequent document created with Copilot assistance, indefinitely, without the original malicious file being present.

This is a document-borne AI worm. It self-propagates through ordinary office workflows. At the time of publication, it remains exploitable with the latest model — GPT-5.6 — with all of Microsoft’s deployed mitigations active. The coordination period agreed between Måløy and Microsoft was 90 days. It was extended twice, ending at 144 days. The attack still works.

I want to be precise about what this means architecturally, why Microsoft cannot easily fix it, and why the current framing of “prompt injection” undersells the severity of what is actually happening.

What the Attack Actually Does

The mechanism is straightforward once you understand how Copilot for Word processes context. When a user asks Copilot to draft or edit a document and attaches source files, Copilot reads all attached files to determine what content to include. It strips text formatting — color, font size — before passing the content to the underlying LLM. This is where the attack lives.

An attacker crafts a document with hidden instructions written in white text on a white background, in font size 8. To a human reader, the document looks clean. To Copilot, which processes stripped plaintext, the instructions are fully visible and carry no semantic marker distinguishing them from legitimate user commands.

The attack payload has two components:

• Stage 1 — foothold: Instructions that cause Copilot to alter the document being drafted. Måløy demonstrated this by instructing Copilot to halve all financial figures in a Q1 report. Copilot executed the instruction, made no mention of the changes, and produced a document with systematically falsified numbers that would pass a casual human review.
• Stage 2 — propagation: Instructions that cause Copilot to copy the entire malicious payload — white text, tiny font, full instruction set — into the bottom of the newly created document. That document is now a carrier. The next time any colleague uses it as a source file in a Copilot drafting session, the attack triggers again.

The original malicious document is no longer required after Stage 1. The attack has moved into internally generated files signed off by legitimate employees. It persists inside the organization’s document corpus without any further attacker involvement.

The Disclosure Timeline Is the Most Damning Part

Måløy reported the initial vulnerability to MSRC on March 6, 2026. Microsoft confirmed the behavior on March 31. A first mitigation went live on April 3 — the new “Edit with Copilot” experience. Måløy verified that the original payload was mitigated. Then he found a new payload that bypassed it, reported it the same day, and Microsoft opened a second case.

On July 14, Microsoft deployed a second mitigation: upgrading the underlying model from GPT-5.5 to GPT-5.6. The next day, July 15, Måløy reproduced the attack in full using GPT-5.6. He voluntarily extended the disclosure window by two more weeks to give Microsoft more time. On July 28, with the attack still reproducing, he published.

This pattern — close the specific payload, leave the vulnerability class open — is exactly what security researchers mean when they say a fix “addresses the symptom, not the root cause.” Each of Microsoft’s two mitigations was payload-specific. The underlying trust boundary violation remained untouched.

I’ve worked on platform security in contexts where the trust model is the product. The temptation to ship a mitigation that closes the reported PoC is real: it satisfies the bug tracker, it satisfies the CVD partner, and it gives you something to announce. What it doesn’t do is close the class. Måløy’s disclosure makes explicit what the class is, and why closing it is hard.

Why This Is an Architectural Problem, Not a Patching Problem

The core issue is something Måløy describes precisely in his closing section, and it’s worth dwelling on because it’s not obvious until you think about it carefully.

For Copilot to be useful, it must process external documents. To process those documents, their content must enter the model’s context window. Once content is in the context window, it participates in the same computation as system instructions and user requests. There is no reliable mechanism within current LLM architectures to mark tokens as “data to be processed” versus “instructions to be followed.” The model infers intention from semantics, and it does this in a single forward pass over the combined context.

This means the attack surface is fundamental. It is not a bug in Copilot’s implementation. It is a property of how large language models process text. The content being inspected participates in the act of inspection. An attacker-controlled document that Copilot reads to decide whether it’s relevant is already influencing the model’s behavior before that determination is made.

The obvious mitigation idea is to put a guard model in front of the main model — another LLM that scans incoming documents for malicious instructions before they reach Copilot. Måløy addresses this too: a guard model weaker than the target model will cover a smaller representational space, leaving attack formulations the target understands but the guard misses. A guard model with equivalent capability creates an “LLMs all the way down” regress. Neither approach closes the class.

What would actually help? Structural separation. The goal is to ensure that the model has reliable access to its own goals and intentions independently of the content it is processing. This is not a feature you can add to a deployed system. It requires rethinking how agent workflows are architected — likely with privilege levels, signed instruction channels, or some form of capability separation that is verified outside the model’s inference path. None of this exists in production LLM systems today, including GPT-5.6.

The Self-Propagation Dimension Makes This Qualitatively Different

Most prompt injection discussions frame the problem as: attacker gets user’s AI assistant to do something bad in a single session. That’s bad enough. The Copilot worm is different in kind because of Stage 2.

Once the attack has moved into an internally generated document, it has acquired organizational legitimacy. The carrier file was created by a legitimate employee, reviewed (partially) by a legitimate employee, and lives in the organization’s SharePoint or OneDrive. When a colleague uses it as source material — a completely normal workflow — they are using a trusted internal document. They have no reason to treat it as untrusted. The attack surface has moved from “external documents” to “your colleagues’ files.”

The traceability implications are severe. Copilot edits, once approved by the user, are not preserved as a separate audit trail. The resulting document looks like a normal document. An organization trying to determine whether its financial reports have been systematically tampered with cannot inspect a diff. It has to compare output to source data manually, across every document produced with Copilot assistance during the exposure window. If the organization didn’t know it was exposed — which is the default case — it doesn’t know when the exposure window started.

Måløy makes a point worth highlighting: organizations that don’t know they’re infected are likely to spread the attack to partners through shared SharePoint sites and Teams. The initial infection vector for a second organization could be a trusted document from a trusted partner who was themselves infected. The attack does not require the original malicious document to travel. Only the carrier does.

How to Actually Detect This in Your Environment Today

Before getting to the bigger architectural picture, I want to address the practical question that security teams will ask immediately: can we detect whether our document corpus has already been compromised? The answer is: partially, for unsophisticated attackers.

The Måløy PoC uses two concealment techniques: white text on a white background, and font size 8. Both are preserved in the Word document’s XML structure (OOXML format) even though they’re invisible on screen. A detection script does not need to render the document — it needs to parse the underlying XML.

A .docx file is a ZIP archive. Inside it, word/document.xml contains all text runs with their formatting properties. A text run with <w:color w:val="FFFFFF"/> or <w:sz w:val="16"/> (font size 8pt is 16 half-points in OOXML) is suspicious if it contains substantial content. The following logic catches the naive implementation:

import zipfile, xml.etree.ElementTree as ET, re

def find_hidden_runs(docx_path):
    ns = {'w': 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'}
    with zipfile.ZipFile(docx_path) as z:
        tree = ET.fromstring(z.read('word/document.xml'))
    suspicious = []
    for run in tree.iter('{http://schemas.openxmlformats.org/wordprocessingml/2006/main}r'):
        rpr = run.find('w:rPr', ns)
        if rpr is None:
            continue
        color = rpr.find('w:color', ns)
        sz = rpr.find('w:sz', ns)
        text_els = run.findall('w:t', ns)
        text = ''.join(t.text or '' for t in text_els)
        if not text.strip():
            continue
        white = color is not None and color.get('{http://schemas.openxmlformats.org/wordprocessingml/2006/main}val', '').upper() in ('FFFFFF', 'WHITE')
        tiny = sz is not None and int(sz.get('{http://schemas.openxmlformats.org/wordprocessingml/2006/main}val', '24')) <= 16
        if (white or tiny) and len(text.strip()) > 20:
            suspicious.append({'text_preview': text[:120], 'white': white, 'tiny': tiny})
    return suspicious

Run this across your shared document libraries and flag any results for manual review. This catches the disclosed PoC approach. A more sophisticated attacker can embed instructions using Unicode lookalike characters, steganographic encoding in metadata fields, or field codes that Copilot resolves at runtime — none of which this script catches. But most attackers are not sophisticated, and a scan that stops the straightforward attack is better than no scan.

For enterprise-scale detection, Microsoft’s own compliance tooling — Purview Content Explorer — can be configured to search for hidden text patterns across SharePoint and OneDrive. It doesn’t natively flag white-on-white text, but document inspection policies can be extended. This is currently manual configuration that no Microsoft deployment guide I have seen recommends as a default.

The deeper problem with detection is timing. Even if you run this scan today and find nothing, that tells you nothing about whether your document corpus was compromised last month, two months ago, or longer. Documents generated by Copilot during an exposure window may have already been shared with partners, submitted to regulators, used as the basis for financial decisions, or archived. Clean documents today do not imply clean documents in the past, and Copilot does not maintain an audit trail of what model edits were made before user approval.

Why Copilot’s Integration Trajectory Makes This Worse

Microsoft has been deepening Copilot’s integration into workflow automation through products like Microsoft Cowork and Microsoft Scout, which extend AI assistance to autonomous document manipulation and collaborative workflow orchestration. These are not hypothetical. They’re shipping features.

In a system where Copilot operates with minimal human approval gates — generating documents, filing them, sharing them, and ingesting the results in downstream pipelines — the propagation mechanism described here scales at machine speed rather than human workflow speed. A document worm that requires a human to open a file and interact with Copilot once per propagation hop is already concerning. A document worm in an autonomous agent pipeline that processes hundreds of documents per hour is a materially different threat.

The underlying mechanism is the same. The attack surface expands proportionally to how much of the workflow Copilot touches autonomously. This is not a future risk. It is a current architectural decision being made by Microsoft product teams while the vulnerability class remains open.

The Historical Parallel Worth Taking Seriously

The word “worm” is accurate in the computer security sense, and the parallel to early network worms is more than rhetorical. The Morris Worm in 1988 infected roughly 6,000 Unix machines — a significant fraction of the internet at the time — by exploiting a trust relationship: the sendmail debug feature would execute commands sent to it, because it was designed to process external input and the designers did not consider that input might be adversarial. The exploit did not require any system to be misconfigured. It required only that systems were deployed in their default state.

The Copilot worm has the same structural property. Copilot for Word in its default, correctly deployed, fully patched configuration is vulnerable. No user has done anything wrong. The attack surface is not a misconfiguration — it is the intended behavior of the product, operating as designed, on inputs that were not anticipated to be adversarial.

The difference in deployment scale dwarfs 1988. Microsoft 365 Copilot is deployed at tens of thousands of enterprise organizations. The current Microsoft 365 commercial subscriber count exceeds 400 million seats globally. Not all of those have Copilot enabled, but the licensed Copilot for Microsoft 365 user base is in the tens of millions and growing. The attack vector requires only that one person at one organization download a malicious document and use it as source material in a single Copilot drafting session. From there, propagation is handled by normal business workflows.

The 1988 Morris Worm spread because network connectivity was new and the security implications of processing remote input were not yet understood. The Copilot worm spreads because document-integrated AI is new and the security implications of processing LLM-mediated document input are not yet understood — by the same organizations that have been building secure network software for forty years. The pattern is identical. The context is new. The lesson has not transferred.

I’m not making this comparison to alarm. I’m making it because the response cadence matters. In 1988, the community’s response to Morris was CERT, hardening guidance, patching, and eventually a much more security-conscious culture around network software. The equivalent response for LLM-integrated software is not yet happening at the same speed. The research exists. The frameworks for thinking about trust boundaries in LLM contexts exist in academic literature. What doesn’t exist yet is the industry-level response — changed procurement criteria, changed deployment defaults, changed security assessment frameworks — that would indicate the lesson is being applied.

What Enterprise Procurement Should Actually Ask

The standard enterprise procurement checklist for a productivity software purchase asks about SOC 2 Type II certification, data residency, GDPR compliance, role-based access controls, and SSO integration. None of these questions address the vulnerability class Måløy disclosed. They are questions about data handling and access control — both legitimate concerns — but they do not address whether the software can be made to alter documents it’s drafting without the user’s knowledge, and whether those alterations can be made to propagate.

A procurement team doing due diligence on Microsoft 365 Copilot today should be asking:

• Does the product maintain an auditable record of all model-generated edits made to a document before user approval, and is that record stored separately from the document itself?
• What controls exist to prevent externally sourced document content from being interpreted as user instructions by the LLM?
• Has the vendor commissioned or published third-party security research specifically evaluating cross-document prompt injection in the context of this product?
• What is the vendor’s current status on the vulnerability class disclosed in CVD case MSRC-2026-[case number], and what is the expected timeline for a class-level fix?
• Are there deployment configurations that restrict Copilot’s ability to produce output that contains hidden text, and if so, what is the mechanism and how is it enforced?

None of these questions are answerable with “yes, we have SOC 2.” They require architectural clarity that most vendors have not been asked to provide, because most procurement teams do not yet know these questions exist. Måløy’s disclosure makes the questions legible. That is, on its own, a significant contribution to enterprise security practice.

Microsoft’s Response, Accurately Characterized

I want to be fair to Microsoft here, because the disclosure was handled professionally and Måløy acknowledges it. MSRC responded within three days of the initial report. Microsoft confirmed the behavior within 25 days. Two mitigation efforts were deployed. The disclosure period was extended twice at both parties’ requests. This is how coordinated disclosure is supposed to work, and it is more than most vendors do.

What Microsoft could not do is fix the underlying problem. That is not a failure of effort; it is a reflection of the actual difficulty. Closing a specific payload while leaving the class open is not negligence — it is rational triage when the alternative is shipping nothing while you wait for a solution to a hard architectural problem. The patches meaningfully raised the bar for unsophisticated attackers. The bar for sophisticated attackers remains the same: craft a payload that the guard model doesn’t recognize but the target model does. That bar is low relative to the sophistication required by most enterprise attacks.

The honest version of Microsoft’s current status is: the attack class is open, no robust mitigation exists, the vendor is aware, and customers should operationally reduce their exposure by treating externally sourced documents as untrusted when used with Copilot.

What “Treating Documents as Untrusted” Actually Means in Practice

Microsoft’s own disclosure guidance says customers can reduce exposure by treating externally sourced documents as untrusted when used with Copilot, reviewing attached documents before starting a Copilot session, and carefully reviewing Copilot-generated output before reusing or distributing it.

This is accurate advice and essentially useless at scale. Let me explain why.

The entire value proposition of Copilot in document-heavy workflows is that it saves review time. An analyst using Copilot to synthesize twenty market reports into a summary is not going to manually read all twenty reports first — that would defeat the purpose. The Copilot session is the review. Asking users to review documents before using Copilot, and then carefully review Copilot’s output, and then also validate that Copilot didn’t embed invisible text in the document it produced, describes a workflow that is more burdensome than not using Copilot at all.

In practice, the workable mitigations are narrower:

• Never use externally sourced documents as direct Copilot context. Copy-paste relevant excerpts manually, or extract text programmatically and validate it before passing it to Copilot. This is technically possible. It eliminates most of the use case that makes document-integrated AI useful.
• Audit your document corpus for hidden text. A script that extracts all text from Word documents and flags content in white font or extremely small font is not complex. Running it on shared drives on a schedule would catch at least naive instances of this attack. Sophisticated attackers can use other hiding methods — but most attackers aren’t sophisticated.
• Disable autonomous Copilot edit features in high-stakes workflows. Financial reporting, legal drafting, and HR document workflows are the obvious candidates. Using Copilot for summarization without document editing capability reduces the attack surface significantly.
• Treat Copilot-generated documents as unverified until diffed against sources. This means preserving source documents and comparing numeric values against them. Laborious, but the only way to detect the specific attack Måløy demonstrated.

None of these mitigations are appropriate for organizations that bought Microsoft 365 Copilot expecting to accelerate their document workflows. They describe a security-conscious power user configuration, not a default enterprise deployment. The gap between what Microsoft is shipping and what its security guidance currently implies is material.

What This Disclosure Tells You About AI Security Research Right Now

The Context Collapse series — Måløy’s three-part disclosure covering Copilot memory poisoning, email-based prompt injection, and now document-borne worm propagation — is the kind of work the field needs more of. It is methodical, it follows coordinated disclosure norms, it gives the vendor time and extends it voluntarily, and it publishes anyway when the attack remains exploitable after 144 days because defenders cannot protect against a risk they don’t know exists.

This is not the first document-borne AI worm. The Morris II research demonstrated self-replicating prompt propagation in email-assistant ecosystems. The difference is that Morris II was a research prototype. Copilot for Word is installed across millions of enterprise seats. The attack surface is not theoretical.

What Måløy’s research illustrates, and what I think is under-discussed in the AI security community, is that the standard model for vulnerability management — report, patch, close — does not map cleanly onto LLM-integrated systems when the vulnerability is architectural. You can patch the payload. You cannot patch the trust model without rearchitecting the system. And you cannot rearchitect the system without shipping something that doesn’t exist yet.

This puts enterprise buyers in an uncomfortable position. You are being sold workflow automation built on a substrate that cannot currently make reliable guarantees about input integrity. The vendors know this. The researchers who study it know this. Most enterprise security teams and most procurement committees do not know this, because the framing they receive is “AI-powered productivity” rather than “LLM integration with unresolved trust boundary architecture.” The information asymmetry is not accidental — it follows from the incentives of companies whose revenue depends on broad adoption. Disclosure like Måløy’s is one of the few mechanisms that closes that asymmetry, which is precisely why it matters that the disclosure happened and why treating it as a niche security research finding would be the wrong response.

Predictions

These are falsifiable claims about how this plays out. Check back in twelve to eighteen months.

• Microsoft will not deploy a robust class-level fix for document-borne prompt injection in Copilot for Word by July 2027. The engineering problem is genuinely hard, the commercial pressure to keep Copilot fast and capable points against the structural changes required, and no comparable product has solved this class either. What they will deploy: more payload-specific mitigations, better logging, and possibly a classification layer that reduces success rates against unsophisticated payloads.
• A real-world exploitation of this class — not a research PoC — will be publicly attributed by mid-2027. The attack is straightforward to execute. The target population is large. The dwell time is long because detection is hard. This is exactly the profile of an attack that gets exploited in the wild before a fix exists.
• Autonomous Copilot features (Cowork/Scout) will be the vector that makes this a boardroom-level incident, not individual Copilot for Word sessions. Human-in-the-loop workflows constrain propagation speed. Autonomous pipelines remove that constraint. The first publicly disclosed incident involving multi-document contamination at scale will involve an autonomous agent feature, not a user who forgot to review their attachments.
• Within 18 months, “prompt injection audit” will be a line item in enterprise security assessments for any organization running Microsoft 365 Copilot in document-heavy workflows. The tooling doesn’t exist today. Someone will build it. The demand is real, even if most organizations don’t know it yet.

The fundamental constraint here is not Microsoft’s commitment to security — the disclosure process was handled well — nor the skill of the engineers working on mitigations. It is that the vulnerability lives in the architecture of LLM inference, and the commercially viable path to fixing it has not been found. Until it is, every organization running document-integrated LLMs is running a workflow that assumes input integrity it cannot verify. That is worth knowing.

Håkon Måløy published three coordinated disclosures across five months, extended the deadline voluntarily when asked, and disclosed publicly only when no robust mitigation was available and defenders could not protect what they didn’t know existed. That is responsible security research done correctly. It deserves a response from the industry that matches its quality: not reassurances about ongoing mitigation work, but an honest accounting of what the architecture can and cannot guarantee, and a realistic timeline for what structural solutions might look like. We are not yet having that conversation at the level it requires.