An example of Morris II Worm: RAG-Based Attack is malicious content inserted into retrieved documents or stored prompts so an LLM repeatedly reuses it and spreads the payload across sessions or connected systems. Defenders should sanitise retrieved text, limit tool actions from untrusted content, and monitor for recursive prompt injection and abnormal propagation paths.
How Morris II Works in a Real RAG Workflow
In practice, the attack starts when a retrieved source is treated as trustworthy enough to influence the next model step. The malicious payload can live in an indexed document, a stored prompt, a note, or any retrieved artifact that the LLM re-reads. RAG security guidance matters here because the weakness is not just bad content, but bad content being allowed to shape later generations and downstream actions.
A concrete example is a knowledge base where one poisoned document contains instructions that survive retrieval and get echoed into later sessions. If the application lets the model copy that text into summaries, tool calls, or follow-up prompts, the payload can propagate beyond the first query. That makes the attack feel worm-like, because the harmful instruction is reused rather than merely displayed once.
This is why the issue is best understood as a retrieval-and-propagation problem, not a simple prompt-injection problem. The model is not “infected” in a permanent sense, but the workflow repeatedly reintroduces the same untrusted material. A well-designed RAG pipeline should therefore treat retrieval output as untrusted input, even when it came from an internal index.
What the Attack Can Spread To
The practical danger is not limited to one chat thread. Once malicious retrieved text enters a workflow, it can contaminate summaries, shared memory, automated tickets, agent handoffs, or any connected system that consumes the model output. Permission-aware RAG design is important because over-sharing at retrieval time makes propagation much easier.
In stronger failures, the content can influence tool use. If the system allows the model to act on retrieved instructions, a poisoned passage may cause repeated external lookups, data exfiltration, or further insertion of crafted content into other repositories. The worm-like effect appears when the output of one step becomes the input to another, and the malicious payload survives each hop.
A second practical pattern is cross-session spread. One user triggers the poisoned retrieval, the model stores or reuses the result, and a later user receives the same compromised guidance. That is especially dangerous in enterprise search, assistant memory, or shared workspace assistants, where users assume the system is merely answering, not redistributing hostile instructions.
Why Defenders Should Care About Recursion and Containment
Morris II style attacks succeed when the defender assumes retrieved text is passive. In reality, the payload can be recursive: it asks the model to restate, preserve, or reinsert itself so the contamination continues. RAG security guidance is useful because it ties the attack to corpus poisoning, grounding failures, and vector store abuse, not just one-off prompt tricks.
The key operational question is whether the system can limit the blast radius of untrusted content. If retrieved text can trigger tools, write back to memory, or influence multiple agents without inspection, then a single poisoned item can become a propagation path. If those capabilities are constrained, the same payload is more likely to remain a contained nuisance than a spreading event.
That distinction matters for both detection and recovery. Teams need to know where retrieved content is stored, which downstream systems consume it, and whether those consumers can re-emit the same text. Without that map, it is hard to tell whether a suspicious output is a local anomaly or part of a wider contamination chain.
Risk and Threat Considerations
The main risk is that a single poisoned retrieval becomes a repeatable propagation path across sessions, users, or connected systems. That creates integrity loss first, then potential confidentiality or action-based impact if the model is allowed to execute tools or write back into shared stores.
Failure mechanism: The attacker places hostile instructions in content that the RAG pipeline retrieves, then relies on the model to reuse that content in later prompts, summaries, memories, or tool calls.
Impact: The payload can spread further than the original retrieval, causing repeated prompt injection, contaminated outputs, unsafe tool actions, and broader trust in the assistant to degrade.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest is Protected | RAG content stored in indexes and memory must stay protected from poisoning and tampering. |
| PR.AA-05 — User Credentials, Authentication, and Authorization are Managed | RAG propagation depends on who may retrieve, write, or trigger tool actions from content. | |
| DE.CM-01 — Networks and Network Services Are Monitored to Find Potential Cybersecurity Events | Recursive prompt injection needs monitoring for abnormal propagation and reuse paths. | |
| Recommendation — Protect stored retrieval data so poisoned content cannot silently persist in the corpus. Enforce authorization on retrieval, memory writes, and tool-triggering paths. Monitor for unusual retrieval repetition, recursive prompts, and propagation chains. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tool-use abuse in RAG agents can turn poisoned content into unauthorized actions. |
| Recommendation — Restrict tool-triggered functions so retrieved text cannot invoke disallowed actions. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Detection of recursive prompt injection depends on logging and traceability. |
| Recommendation — Log retrieval, prompt reuse, and tool invocation paths for anomaly review. | ||
Practitioner Guidance
What to verify: Confirm that retrieved text is filtered, attributed, and constrained before it can influence tools, memory, or downstream prompts. The most important check is whether untrusted retrieval can change state anywhere outside the current response.
Decision rule: If the retrieved item could be copied into another user-visible or machine-actionable context, treat it as a propagation risk and contain it before you optimise relevance or answer quality.
What good looks like: A safe RAG workflow separates retrieval from execution, tags untrusted content, blocks recursive prompt patterns, and logs unusual reuse paths so repeated spread is visible early.
Practitioner takeaway: The real control objective is not simply to detect malicious text, but to stop retrieved content from becoming a self-replicating instruction path.