In June 2025, Microsoft patched a vulnerability in Microsoft 365 Copilot tracked as CVE-2025-32711, CVSS 9.3, and named EchoLeak by the researchers who found it at Aim Labs (Aim Security). It's widely described as the first publicly documented zero-click prompt injection against a production LLM application — and the first time prompt injection was shown to cause concrete data exfiltration, not just a misbehaving response.
The part worth sitting with: the victim never clicked anything.
What happened
The attack starts with an ordinary-looking email sent to a target's inbox. Inside that email is a payload written in markdown, phrased as instructions for the language model rather than for the human reading it. The recipient does not need to open it, click it, or act on it in any way.
Later, the user asks Copilot a normal business question — summarize my recent documents, that kind of thing. To answer, Copilot's retrieval layer (RAG) pulls in relevant context, and the attacker's email gets swept into that context alongside the user's genuinely sensitive data: OneDrive files, SharePoint content, Teams messages, chat history. Now the malicious instructions are sitting in the same prompt as the data the attacker wants.
The model follows the injected instructions. It assembles internal data into a URL and embeds that URL as a markdown image. When the client renders the response, it auto-fetches the image — and the fetch is the exfiltration. The sensitive data leaves as query parameters on an outbound request the user never authorized and never sees.
Aim Labs chained several bypasses to make this work end to end: evading Microsoft's cross-prompt-injection (XPIA) classifier, slipping past link redaction using reference-style markdown, abusing the auto-fetch behavior of images, and routing the egress through a Microsoft Teams proxy that the content-security policy already trusted. Microsoft fixed it server-side; there's no evidence it was exploited in the wild. You can read Aim's original write-up and a good summary at The Hacker News.
Why it matters
Most prompt-injection demos require a person to paste hostile text or click a poisoned link. EchoLeak removed the human from the loop entirely. The untrusted content arrived through normal email plumbing, got mixed with trusted data by the assistant's own retrieval design, and left through a rendering feature that was working exactly as built.
This is indirect injection at the infrastructure boundary. Nobody on the defending side made a mistake in the human sense — no bad click, no ignored warning. The vulnerability lived in the seams: how retrieved content is trusted, how output is rendered, and where outbound requests are allowed to go. Those are the seams every RAG-based assistant has, which is why this is treated as a class of problem rather than a one-off Copilot bug.
The practitioner takeaway
You cannot reliably stop a model from being persuaded by text it retrieves. EchoLeak chained around the classifier built specifically to catch this. So design as if the injection lands, and make sure that when it does, there's nowhere for the stolen data to go.
- Treat every retrieved or auto-fetched item as untrusted input — including email, documents, and web pages. Content that enters the model's context is attacker-controllable, even when it arrives through a channel you consider internal. Don't grant retrieved text the trust you'd give a user instruction.
- Assume injection sometimes succeeds, and bound the blast radius. Scope what the assistant can read for any one task to what that task actually needs. The reason EchoLeak was severe is that a single query had reach across OneDrive, SharePoint, Teams, and chat at once. Narrow that and you cap the worst case.
- Control egress so exfiltration has nowhere to land. The data left via an auto-fetched image URL to an allowed proxy. Don't auto-fetch remote resources from model output, strip or sandbox outbound links and images before rendering, and allowlist the destinations the assistant can reach. If the only way data leaves is a path you explicitly opened, a successful injection produces nothing.
The fix isn't a smarter filter at the front door. It's accepting that the front door will occasionally be walked through, and making sure the back door is locked.
This incident is one of the sources behind *BRACE*, an open, vendor-neutral framework for securing autonomous AI agents — its run-time guide is built on the assumption that injection sometimes succeeds, so you design for the after-state. BRACE is built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?
Top comments (0)