Originally published on The AI Prism
The First AI Worm Isn’t Hypothetical Anymore
Picture this: you’re an analyst at a mid-sized company. You download a market analysis from a trusted industry website to use as source material for a financial report you’re drafting in Word. You ask Copilot to pull the key figures and structure the document.
Somewhere in that download, buried as white text on a white page, is a set of instructions you never saw. Copilot reads them anyway. It treats them as part of your request, quietly alters numbers inside your report, and appends the same hidden instructions into the finished document — a fresh carrier, ready for the next person.
You save the report and share it internally. A colleague uses it as source material for their own document. The instructions trigger again. The attack keeps moving through your organization, document by document, with no malware, no macros, no exploit, and no signature for your security stack to catch.
The first AI worm isn’t a hypothetical anymore. It’s already crawling through ordinary Word workflows. This week, security researcher Håkon Måløy published a detailed technical write-up showing exactly how it works in Microsoft Copilot for Word. The story hit 380 points and 294 comments on Hacker News in under a day, and Malwarebytes covered it within 48 hours. Here’s what it means.
The Attack: White Text, No Signature
The technique is almost embarrassingly simple — which is exactly why it’s dangerous.
An attacker hides a JSON-formatted prompt as white text on a white background inside a Word document. To a human, the document looks normal. To Copilot, the text is just another part of the document’s content. When the file is attached as source material for a drafting or editing task, Copilot strips away the formatting, reads the hidden text, and interprets the embedded instructions as part of the user’s request.
The instructions can make Copilot do two things at once: manipulate the document being drafted or edited, and copy the full malicious prompt back into the new document as hidden text. That output document becomes a new carrier. The next time anyone uses it as source material, the cycle repeats.
There’s no payload to execute and no binary to detect. The “infection” is a document that looks legitimate because it was created by a legitimate user in a legitimate tool. The researcher’s example is a financial report with internal figures silently altered — the kind of edit that would be caught weeks later, if ever, when the numbers don’t add up.
The propagation vector is your own infrastructure: SharePoint, Teams, Outlook, or any other way documents get shared between colleagues. The attacker only needs to get one poisoned document in front of one employee.
A Worm Without a Body
Is it fair to call this a worm? Technically, yes — and the definition matters.
A worm is malware that self-propagates: it replicates and spreads without human intervention beyond the initial trigger. This attack does exactly that. One document becomes two. Two become ten. The replication happens inside Copilot’s normal operation, and the attacker doesn’t need to be present after the first document lands.
This isn’t the first AI worm. In 2024, researchers Ben Nassi, Stav Cohen, and Ron Bitton demonstrated Morris II — self-replicating prompt injection that spread through GenAI-powered email assistants. Their paper’s subtitle called it what it was: a zero-click worm. No user action required beyond opening the poisoned message. But as Måløy notes, this new work is among the first public demonstrations of a document-borne AI worm self-propagating through normal workflows in a mainstream commercial productivity suite. Not a research sandbox. Word. The tool more than a billion people use for work.
The Hacker News thread drew the obvious historical comparison: “It’s VBScript/macro worms all over again!” The parallel is real, but the difference matters more. Macro worms needed code execution — the old arms race of signatures, heuristics, and sandboxing. This worm needs only text. It’s not executing anything. It’s being asked to spread by a system that can’t tell the difference between a user’s instruction and an attacker’s.
The 144-Day Game of Whack-a-Mole
The most damning part of this story isn’t the attack itself. It’s the timeline.
Måløy reported the vulnerability to Microsoft’s Security Response Center (MSRC) on March 6, 2026. Microsoft confirmed the behavior on March 31 and began mitigation work. Here’s what happened next:
• April 3: First mitigation ships — a new “Edit with Copilot” experience.
• April 9: The original attack prompt is verified mitigated. Then the researcher reproduces the attack against the new experience with a different prompt, this time manipulating financials. Reported as a separate case.
• June 8: At Microsoft’s request, public disclosure is pushed to July 15.
• July 14: Second mitigation ships — an upgrade to the underlying model, GPT-5.5.
• July 15: The researcher successfully reproduces the full worm chain on GPT-5.6, the latest model available. He suggests postponing disclosure another two weeks.
• July 28: The attack class still reproduces. Coordinated disclosure goes public — 144 days after the initial report.
Read that again: two mitigations, including a model upgrade, and the vulnerability class survived both. At publication, Microsoft’s own status is blunt: no robust mitigation for the broader vulnerability class is available, and customer-side remediation doesn’t fully address the issue either.
This is what a whack-a-mole defense looks like when the mole is an architectural property, not a bug.
The Trust Tax on AI
There’s a quieter casualty in this story, and it hits every organization that has started leaning on AI assistants: trust.
Prompt injection has held the #1 spot on the OWASP Top 10 for LLM Applications since the list’s first edition in 2023. Security professionals have known this class of attack was coming for years — it was demonstrated against Bing Chat in 2023, against ChatGPT plugins in 2023, against email assistants in 2024. The demonstrations kept getting more practical, and the industry kept shipping assistants with broader and broader access. This Word worm is what that trajectory was always building toward.
The result is a tax on every AI-assisted workflow. When a report has been through Copilot, you can no longer be sure the numbers came from the source documents — or that the document you’re reading didn’t just become a carrier for someone else’s instructions. Every AI-generated document now carries a question mark that didn’t exist before. The productivity gain from AI assistants is real; so is the new uncertainty they inject into the documents your business runs on.
This is why the researcher’s decision to disclose at the class level — even though the vulnerability was still exploitable — was the right one. Defenders can’t mitigate a risk they don’t know exists. The 144-day timeline, the two failed mitigations, and the disclosure itself are all information that lets organizations make an informed choice about how much of their document flow they hand to an agent.
Why This Scares Security Teams
Security teams have spent two decades building defenses around the assumption that malicious content has a shape — a file type, a signature, a behavior pattern. This attack has none of the usual ones.
Hidden text is a legitimate Word feature. Track changes, comments, field codes, and white-on-white text are all used daily by normal people. Your security stack isn’t going to flag a .docx with white text, because half the documents in your company probably contain it. And Copilot can’t be told “ignore hidden text,” because hidden content is sometimes exactly what a user wants summarized.
The harder problem is attribution. Every carrier document is created and edited by legitimate users inside the legitimate tool. There’s no malware author to hunt, no C2 domain to block, no binary hash to distribute. By the time someone notices altered figures, the document has already been reused by three other teams.
One Hacker News commenter put the enterprise version of this bleakly: “I mean all your data is already exfiltrated to Copilot, so a little extra worm cannot hurt.” The uncomfortable truth under the sarcasm is that organizations are deploying AI assistants with read-and-write access to their most sensitive documents while the security model for those assistants is still being invented.
The trust boundary failure is the root of it. When you attach a document to Copilot, the system reads it to extract information — but it also treats what it reads as instruction. The researcher’s framing is precise: attached documents should be treated as untrusted information, not trusted user instruction. Today, they’re treated as both, with no separation.
The Root Cause Is Architectural
Strip away the Word-specific details and you arrive at a problem the industry has known about for years: prompt injection.
LLMs share one context window for everything — the user’s genuine request, the retrieved documents, and any attacker-controlled text hidden inside them. The model has no native way to distinguish “instructions from the user” from “instructions found in source material.” That’s the architectural weakness, and it’s why this class of attack keeps surviving patches.
The researcher’s series is literally titled “Context Collapse.” Parts one and two showed how external inputs influence Copilot responses and can leak confidential data through cross-domain prompt injection. Part three shows the same weakness weaponized for propagation. The progression is the story: read the data, then alter the data, then spread the alteration. Each step uses the same underlying flaw.
Malwarebytes’ coverage is blunt about what this means: attacks exploiting this behavior “may never be fixed.” Not because vendors aren’t trying — Microsoft clearly is — but because the fix requires redesigning how LLMs separate trusted instructions from untrusted content. That’s not a patch. That’s a new architecture.
The Agentic AI Reckoning
Zoom out, and this is the moment the agentic AI industry has been dreading.
Copilot for Word is, functionally, an agent: it takes a goal (“draft this report”), reads files, writes files, and acts inside your document environment with your permissions. It’s also the most widely deployed agent on the planet. If this agent — with Microsoft’s security budget, its MSRC process, its 144 days of dedicated mitigation work — can still be turned into a self-propagating worm, what does that say about the thousands of smaller agent deployments happening right now?
The answer, increasingly, is that agent safety isn’t a feature to bolt on later; it’s the product. Every company racing to ship agents with file access, email access, or browser access is inheriting this vulnerability class, whether they know it or not. The researcher chose to disclose at the class level rather than the payload level precisely because defenders can’t mitigate a risk they don’t know exists. That’s the right call, and it’s the uncomfortable gift this story gives the industry: a working demonstration, months ahead of the mainstream, of what agentic AI fails at today.
The pattern of escalation is worth naming, because it will repeat. First, agents read untrusted content (data leak). Then, agents act on untrusted instructions (manipulation). Then, agents propagate untrusted instructions into new artifacts (worming). Each step up the ladder is harder to detect than the last, and each one is already being demonstrated against shipping products. The companies that treat these demonstrations as PR problems will keep losing this race; the ones that treat them as architecture feedback will be the ones still standing when the regulatory floor arrives.
What You Can Actually Do
There’s no complete fix yet — for Microsoft, for Copilot, or for the broader LLM ecosystem. But there are meaningful steps that reduce exposure, and organizations should be doing them now:
• Treat externally sourced documents as untrusted. Anything that arrives from outside your org and gets used with Copilot is a potential carrier. That includes “trusted” industry sites — the researcher’s example assumes a legitimate website that got compromised.
• Review attachments before Copilot generation. A quick scan for suspicious hidden content before drafting is cheap. There’s no reliable automated detector yet, which is exactly why the human step matters.
• Review Copilot output before reuse. The human-in-the-loop isn’t a formality — it’s the only control that currently breaks the propagation chain. Every document that gets reused without review is a link in the chain.
• Don’t feed sensitive documents to Copilot casually. If a document would hurt you if silently altered, it shouldn’t be one click away from an AI edit. Segregate what agents can touch.
• Audit your agent permissions with least privilege. If Copilot or any assistant has blanket access to SharePoint or your document stores, that’s a worm highway. Scope agents to the smallest set of documents they actually need — the same way you’d scope a service account.
• For individual users: disable Copilot if you don’t need it. Word’s File → Options → Copilot has an “Enable Copilot” checkbox. Or turn off optional connected experiences under Account Privacy. Fewer agents with document access means a smaller attack surface, full stop.
For Microsoft and every other vendor shipping agents: the fix isn’t another model upgrade. It’s capability separation — a security boundary between the content an agent reads and the instructions an agent follows. Until that exists, treat every AI-assisted document workflow as a potential worm vector, and budget your incident response accordingly.
The Bottom Line
The AI worm story isn’t a distant threat narrative. It’s a demonstrated, reproducible attack in the world’s most popular productivity software, with a 144-day disclosure timeline proving that current mitigations don’t close the class.
The companies selling AI assistants are betting that trust boundaries can be patched into existence. The researchers breaking them are betting the flaw is deeper — that you can’t bolt security onto a system that can’t tell your words from an attacker’s.
The first AI worm is already here. It’s just waiting for a document.
So here’s the question that should be on every security team’s board this week: How many of your internal documents have already been through a Copilot workflow — and how many of them came from somewhere you didn’t fully trust?
References
• Håkon Måløy — “Context Collapse, Part 3: AI Worming through Word” (En Klype Salt, July 28, 2026)
• Pieter Arntz — “Hidden prompt turns Microsoft Copilot into an AI worm” (Malwarebytes, July 30, 2026)
• OWASP Top 10 for Large Language Model Applications (Prompt Injection — LLM01)
The post The AI Worm Is Already Here — It’s Crawling Through Copilot for Word appeared first on The AI Prism.
Cross-posted from theaiprism.com — Cutting Through the AI Noise 🧊
Top comments (0)