EchoLeak: The Zero-Click Copilot Data Leak Explained
EchoLeak, tracked as CVE-2025-32711, showed how an email could place hostile instructions inside Microsoft 365 Copilot retrieval context and turn a trusted answer into a data-exfiltration path. This analysis separates the injection, retrieval, model, rendering, and network boundaries so security teams can assign controls without overstating what any one gateway can see.
Microsoft assigned CVE-2025-32711 to an AI command-injection flaw in Microsoft 365 Copilot.
The Microsoft Security Response Center record describes network-based information disclosure by an unauthorized attacker and says Microsoft had already fully mitigated the hosted service. Microsoft's advisory required no customer action after that mitigation.
The short advisory leaves the architecture lesson intact. EchoLeak crossed several trust boundaries before confidential data could leave: an email entered the tenant, Copilot retrieved it, the model processed its hidden instruction beside trusted context, and rendered output created an outbound channel. A single label such as "prompt injection" hides the control owner at each step.
TL;DR
- EchoLeak is CVE-2025-32711, a zero-click Microsoft 365 Copilot information-disclosure vulnerability published on 11 June 2025.
- The attack joined indirect prompt injection, trusted retrieval, model-generated output, and an outbound exfiltration channel.
- Microsoft says the hosted service was fully mitigated and customers had no action to take.
- Security reviews should map each transition separately. DeepInspect covers only authenticated HTTP LLM traffic deliberately routed through its proxy.
The EchoLeak attack chain
EchoLeak began with content delivered to a Microsoft 365 tenant. The user could leave the message unopened. Copilot later retrieved that content while answering a legitimate request, which placed attacker-controlled instructions into the model context alongside tenant data. This is the defining mechanism of indirect prompt injection: the instruction arrives through retrieved material rather than through the user's prompt. The public NVD record for CVE-2025-32711 identifies Microsoft 365 Copilot as affected and records no privileges and no user interaction in Microsoft's CVSS vector. Those fields explain the "zero-click" description. They also explain why ordinary awareness training offered little help. The user never had to click a link or approve a dialog.
Picture the event as five boxes on a whiteboard: email, retrieval index, Copilot context, rendered answer, outbound request. Each arrow changes the data custodian. Each box needs a named owner and evidence source.
Retrieval turned untrusted text into model context
A retrieval system chooses material because it appears relevant to a query.
Relevance says nothing about authority. An email that matches the user's topic can enter the context window even when its body contains instructions written by an attacker.
That boundary deserves its own controls. Teams should retain the source identifier, sender trust level, retrieval score, ingestion time, and the exact passages supplied to the model. Content provenance can influence policy before retrieved text reaches inference. Sensitive workloads may exclude external email, newly arrived documents, or sources with weak ownership signals from high-trust retrieval paths. The indirect prompt injection guide covers the broader pattern. EchoLeak makes the pattern tangible because the retrieved item lived inside a trusted productivity suite. My opinion is blunt: a tenant boundary is a storage boundary, not a statement that every sentence inside the tenant deserves instructional authority.
Model context collapsed data and instructions
The model received a combined context containing the user request, system instructions, retrieved email content, and tenant data relevant to the answer. Once those tokens shared one context window, the model had to infer which text represented instructions and which text represented evidence.
The model makes that security inference probabilistically. A stronger system prompt may lower attack success in a benchmark, yet it leaves the model making the security distinction. The prompt injection benchmark comparison shows why static test scores need an adaptive testing plan and a containment layer for residual failures.
A production review should capture the prompt template version, retrieved source list, model route, model version, and any classification applied before inference.
Those records let an investigator reproduce the decision path after a suspicious answer. An application log that stores only the final response throws away the material that explains why the model followed the hostile instruction.
Rendering created a separate exfiltration boundary
The attack needed a way to move selected data out of the Microsoft environment. EchoLeak research focused attention on generated output that could cause a client to fetch an attacker-controlled resource. That transition belongs to output rendering and network egress, separate from the model's decision to produce the content. Controls at this layer include strict rendering rules, URL allowlists, content security policy, image proxying, and egress inspection. A client can render model text as inert text instead of automatically loading remote resources. Security teams should log any generated URL, the component that interpreted it, and the destination eventually contacted.
This distinction prevents a common attribution error. Prompt filtering works before or during inference. Browser and application controls govern what rendered content can cause afterward. The prompt injection versus jailbreak guide separates attacker-supplied context from a user directly challenging model safety, another boundary that changes the control plan.
Microsoft's mitigation and the remaining design work
Microsoft's advisory says the vulnerability was fully mitigated in the hosted service before disclosure, with no customer action required. The MSRC entry classifies the issue as critical, labels the impact information disclosure, credits Aim Labs, and records publication on 11 June 2025. The NVD entry preserves the vendor description and affected product in a second public record.
Customers still need an architectural review because similar chains can appear in other retrieval-augmented applications.
Inventory every source that can enter the context window. Mark which sources can carry external content. Trace generated output through its renderer and outbound network path. Then attach an owner and a retained record to each transition.
The useful exercise ends with a diagram, not a checkbox. One red arrow should show untrusted text entering retrieval. Another should show sensitive context reaching the model. A third should show generated content crossing the client's egress boundary.
DeepInspect
DeepInspect sits between authenticated users or agents and LLM endpoints when the application deliberately routes HTTP model traffic through the proxy. At that boundary, it can evaluate supplied identity context, classify prompt content, enforce route and data policy, inspect the model response, and write a per-decision audit record. For an EchoLeak-style workflow, that coverage applies only to the model request and response that traverse DeepInspect. Email delivery, Microsoft 365 indexing, local rendering, browser resource loading, and outbound requests to an attacker domain sit outside that boundary. Microsoft-hosted Copilot traffic also remains outside DeepInspect unless the customer controls and routes the relevant HTTP model call.
A sound deployment pairs retrieval provenance and rendering controls with identity-aware enforcement on the routed LLM request. That division of labor keeps the claim precise and gives investigators separate records for each arrow in the attack chain. Let's talk today.