A single line of invisible text, hidden inside an ordinary Word document, is enough to turn Microsoft’s flagship productivity assistant into an unwitting courier for malicious instructions — and, according to the researcher who found it, nobody has yet worked out how to stop it for good.
A Worm Made of Words, Not Code
For decades, the word “worm” in computing meant something that exploited a flaw in software code to copy itself from machine to machine. The vulnerability disclosed in the final week of July 2026 by independent researcher Håkon Måløy is different in kind. It does not touch a single line of Word’s underlying code. Instead, it exploits the fact that Microsoft Copilot for Word cannot reliably tell the difference between an instruction from its user and an instruction that happens to be sitting inside the document the user is working with.
Måløy, a Norwegian data scientist with a doctorate in applied AI and machine learning, calls the finding “Context Collapse, Part 3: AI Worming through Word.” It is the third installment in a running body of research into what security professionals label cross-domain prompt injection attacks, or XPIAs — a class of vulnerability unique to large language model-powered software that has no clean analogue in traditional cybersecurity.
How the Infection Spreads
The mechanics are almost unnervingly simple. An attacker crafts a short set of natural-language instructions, formats them as white text on a white background at a barely-visible font size, and embeds them inside an otherwise unremarkable document — a market analysis, a vendor proposal, a shared template. Nothing about the file looks suspicious to a human reader who opens it.
The trouble begins when that document is pulled into Copilot as context for a drafting or editing task. Copilot’s underlying language model reads everything in the file, including text that is functionally invisible to a person, and treats it with the same authority as a direct request typed by the user. In Måløy’s proof of concept, the hidden payload instructs Copilot to quietly alter figures in whatever report the employee is generating and, crucially, to copy the same hidden payload into the newly created document.
That second instruction is what elevates the flaw from a one-off manipulation into a worm. Once the tainted report is finished, it can itself be picked up by a colleague and fed into Copilot as source material for a completely different task. The payload travels with it, altering the new document and replicating itself again. The chain can continue indefinitely, moving through an organization’s ordinary habit of reusing, referencing, and building on each other’s work — long after the original external document that started the chain has been deleted or forgotten.
The attack turns trusted internal files into carriers of an AI worm that propagates via normal collaboration and document reuse, according to the researcher’s published analysis, even after the source document is no longer present anywhere in the organization.
Not a Lab Curiosity
What makes the disclosure notable is how thoroughly it was tested before publication. Måløy reported the issue to the Microsoft Security Response Center on March 6, 2026, and spent 144 days working through a coordinated disclosure process, providing reproduction steps, proof-of-concept prompts, and demonstration videos. During that window, Microsoft shipped a revised “Edit with Copilot” experience and, separately, upgraded the underlying models powering Copilot to newer versions of OpenAI’s GPT family. Both mitigations blocked the specific payloads Måløy had originally submitted.
Reformulated versions of the same attack class, however, continued to work through the end of the disclosure window in late July, which is why Måløy ultimately went public despite the absence of a comprehensive fix. He has deliberately withheld the exact wording of his working payloads, arguing that publicizing the vulnerability class itself is necessary for organizational awareness even though releasing the specific prompts would hand attackers a ready-made toolkit.
Microsoft’s Response
Microsoft’s public statement on the matter, issued to multiple outlets covering the disclosure, acknowledged the researcher’s findings and thanked him for working through coordinated vulnerability disclosure. The company described its approach as a defense-in-depth strategy, using layered safeguards designed to intercept malicious instructions at several points in the pipeline and keep Copilot’s behavior aligned with what the user actually asked for.
That framing matters, because it implicitly concedes what security researchers have been saying for well over a year: indirect prompt injection, as a category, cannot currently be eliminated outright in systems built on large language models. It can only be narrowed, layer by layer, while the underlying architectural problem — a model’s inability to cleanly separate trusted instructions from untrusted content it is merely supposed to read — remains unsolved.
A Pattern, Not a One-Off
This is not Måløy’s first find of the year. In June, he disclosed a separate flaw showing how a malicious web page could trick the “Summarize with Copilot” feature into saving an unwanted memory that would then follow the victim across both browsing and work sessions until manually deleted. That issue was patched organization-wide with no customer action required.
A second bug, catalogued by Microsoft as CVE-2026-55145, showed three distinct ways that hidden instructions inside external emails could manipulate Outlook Copilot: shifting meeting times inside an automatically generated daily summary, inserting attacker-supplied content into outgoing replies, and fabricating a tool-call result convincing enough to make Copilot falsely report that the organization was under active cyberattack. Unlike the memory bug, that fix requires administrators to manually enable an external-sender flag inside Exchange Online — meaning many tenants likely remain exposed simply because nobody has flipped the switch.
Security Experts Are Split
Reaction from the wider security community has been divided. Aman Mahapatra, chief strategy officer at technology consultancy Tribeca Softtech, argued that the finding is more serious than it first appears precisely because it sidesteps almost every defensive control enterprises currently rely on. In his reading, this is a genuine self-propagating malware pattern that uses Copilot itself as the transmission mechanism and ordinary corporate collaboration as the delivery channel — a description that echoes how traditional worms exploited email attachments and shared network drives in an earlier era of malware.
Not everyone is convinced the sky is falling. Tyler Reguly, associate director of security research and development at Fortra, characterized the finding as closer to a laboratory demonstration than an active, in-the-wild threat, suggesting its practical blast radius may be narrower than the more dramatic coverage implies. Other commentators noted a silver lining: because the attack lives inside a single product, Microsoft hardening the Copilot document path directly improves safety for every Copilot customer, independent of whatever the rest of the industry chooses to do.
What This Means Going Forward
For IT and security leaders, the practical takeaway is less about panicking over a specific proof of concept and more about internalizing a structural shift. As AI copilots become embedded in everyday document work, the trust boundary that used to sit between “the internet” and “our internal files” is eroding. A document created entirely by a legitimate employee, using an approved and sanctioned tool, can now become an unwitting attack vector simply by having once referenced the wrong source material.
Expect this disclosure to accelerate conversations already underway inside enterprise security teams: stricter provenance tracking for AI-assisted documents, content-inspection tooling that can flag suspicious hidden text before it reaches a model’s context window, and renewed scrutiny of exactly which external sources employees are permitted to feed into AI assistants in the first place. None of those measures close the underlying gap. They simply make the next worm a little harder to write.
Why “Just Train the Model Better” Isn’t the Answer
A natural instinct, especially for people newer to AI security, is to assume this is simply a matter of better model training — teach the system to recognize and ignore obviously suspicious text, and the problem goes away. Researchers who study prompt injection have spent the better part of two years explaining why that instinct doesn’t hold up. A large language model doesn’t parse a document the way a human eye does, skimming past irrelevant formatting and focusing on visually prominent content. It processes the entire text stream more or less uniformly, regardless of font size, color, or visibility to a human reader. Teaching a model to distrust “white text on a white background” simply pushes attackers toward the next encoding trick — a tiny font in a slightly-off-white shade, text hidden inside an embedded image’s alt description, or content buried inside a document’s metadata fields that a human would never think to inspect but that gets pulled into the model’s context all the same.
This is why security researchers increasingly describe indirect prompt injection as an architectural problem rather than a training problem. The entire value proposition of an AI document assistant is that it reads and acts on the full content of whatever you hand it. Any fix robust enough to fully close that gap would likely have to sacrifice some of the very flexibility that makes tools like Copilot useful in the first place — which is exactly the trade-off Microsoft, OpenAI, Google, and every other vendor shipping AI-powered productivity software is now quietly negotiating in real time, one patch at a time.
What Individual Users Can Actually Do
For everyday Copilot users, waiting on a comprehensive architectural fix isn’t a practical strategy. A handful of habits meaningfully reduce exposure in the meantime: treat any externally sourced document as untrusted context until a human has reviewed it, be skeptical of documents that behave unexpectedly after being summarized or referenced by an AI assistant, and where possible, avoid feeding documents from unfamiliar or unverified sources directly into an AI tool without first opening and visually inspecting them. None of these habits are foolproof against a sufficiently well-hidden payload, but they meaningfully shrink the attack surface until the underlying architectural gap narrows further.
Leave a Reply