One email made Copilot leak private data, and the victim never clicked anything.

The scariest vulnerabilities are the ones where the victim does everything right. EchoLeak is that shape. Aim Labs showed that a single outside email, sitting in a mailbox Copilot could read, was enough to make Copilot leak private data. No click. No download. No suspicious attachment. The victim just used Copilot as usual, and the attacker’s content rode along in the retrieved context.

The case is EchoLeak, CVE-2025-32711. Microsoft’s record calls it “M365 Copilot Information Disclosure Vulnerability.” Microsoft’s own CVSS base score is 9.3, Critical. NIST scores it 7.5, High. Aim Labs disclosed it in June 2025, Fortune reported it took Microsoft five months to address the issue, and Microsoft says it is now fully mitigated with no user action required. Microsoft’s record lists it as not exploited, Aim Labs knows of no affected customers, and the CISA entry in NVD lists exploitation as none. That is the official record, checked against the sources below on October 8, 2026.

How the email got in

Walk the kill chain, because every step is a control you probably own in your own retrieval pipeline.

First, Copilot retrieved the attacker’s email like any other content. Retrieval does not distinguish between your data and an attacker’s data; it ranks by relevance. The email was relevant, so it entered the context.

Second, an injection filter missed it because the email never mentions AI. Filters that look for “ignore previous instructions” and its cousins are pattern matching against known attack phrasing. This email did not use known attack phrasing. It did not need to.

Third, a reference-style markdown link slipped past link redaction. The redaction knew about inline links. It did not catch reference-style links, the [text][id] form with the URL defined elsewhere in the document. One syntax the filter was not taught, and the payload walked through.

Fourth, a Teams URL on the page’s allowlist did the fetch. The exfiltration did not go to some sketchy domain. It went to a URL the allowlist trusted. Allowlists are only as good as their entries, and a trusted domain that renders attacker-controlled content is not a safe destination.

Four controls, four misses, zero clicks.

Where retrieval fits

This is the part that matters for your pipelines. The controls that failed were the injection classifier, link and image redaction, and the allowlist. But retrieval is where the email entered the context. Everything downstream operated on poisoned input and behaved exactly as designed.

That is the uncomfortable shape of retrieved-context poisoning. Your generation guardrails can be perfect and it does not matter, because the poison entered upstream of all of them. The fix lives at the retrieval layer: what you index, how you rank, what you redact before it reaches the model, and what destinations your outputs are allowed to touch.

A note on honesty: the four checks are our inference from the Aim Labs write-up, not Microsoft’s fix. Microsoft’s record says the issue is fully mitigated. What Microsoft fixed internally and what you should check in your own pipeline are two different lists. Ours is the second one.

The eval angle

Retrieval failures like this one are exactly what evals are for. A graded QA set that includes adversarial documents, run on a schedule, would have shown the injection filter missing novel phrasing before an attacker did. Evals are how you catch retrieval-quality failures in staging instead of reading about them in a disclosure.

The question from the carousel stands, and it is a good one to take into your next incident review: how many of the four controls does your retrieval pipeline have today? Drop a number. Then go build the ones you are missing.

This post started as an Instagram post →