The phishing link in this attack points to microsoft.com. That is the whole problem. Varonis Threat Labs built a chain it calls SearchLeak that turns one click on a real Microsoft URL into a quiet theft of a user's mailbox, files, and one-time codes, and nothing in a standard URL filter or phishing-awareness program is built to stop a link to a first-party domain.
Microsoft tracked it as CVE-2026-42824, rated it critical, and fixed it on the backend at the start of June 2026. Varonis reported a proof of concept, not exploitation in the wild, so there is no emergency patch to chase. The reason to read on is the shape of the bug, because the parts that made it work are coming back.
What SearchLeak actually does
SearchLeak chains three weaknesses in Microsoft 365 Copilot Enterprise Search. On their own, each is minor. Together they form a single-click exfiltration path.
The first is a prompt injection through the search URL. The q parameter in Copilot Search is handed to the model as an instruction, not just a query string. Put text in q and Copilot will try to follow it. Because Copilot Enterprise runs with the signed-in user's permissions, those instructions inherit access to everything that user can read.
The second is a timing flaw in how the answer renders. Copilot streams its response into the page while it is still being generated, as Varonis describes. An <img> tag in that stream fires an HTTP request to its src the moment the browser sees it. Microsoft's sanitizer wraps unsafe output in a <code> block, but that runs after generation finishes. The request has already left.
The third is where the stolen data goes. Bing's image-search endpoint sits on Copilot's content-security-policy allowlist, and that endpoint performs a server-side fetch of any image URL you hand it. Point the <img> at bing.com/images/searchbyimage with the victim's data encoded in the path, and Bing itself reaches out to the attacker's server. The data lands in the attacker's logs, sent from Microsoft's infrastructure, past a CSP that was doing exactly what it was told.
The injected prompt tells Copilot to read an email, take its subject, and stitch it into that image URL. The victim sees Copilot "thinking" and nothing else.
Why your URL filtering never had a chance
Reputation and signature URL protection works by asking whether a domain is trustworthy. Here the answer is yes. The link is microsoft.com, the user is already authenticated to it, and the payload lives in query parameters that no blocklist scores as hostile.
This is first-party phishing, and it breaks the kill chain teams spent a decade building. Click-awareness training tells people to check the domain before they click. They check, they see microsoft.com, they click. The lesson is not "train harder." It is that the trusted-domain assumption underneath most email and web filtering does not survive an AI feature that runs attacker text on a first-party host. We saw a version of this when PeopleSoft's own patch service became the breach: the thing you trust by default is the thing worth attacking.
Your CSP allowlist is now an exfiltration map
Most teams read a content-security-policy allowlist as a loading rule: these are the domains my app may pull resources from. SearchLeak shows the other reading. Any allowlisted domain that performs a server-side fetch on user-supplied input is a ready-made exfiltration channel, and an attacker who can shape page content will find it.
Walk your allowlists with that question in hand. For every entry, ask whether that service will fetch a URL you give it. Image search, link unfurlers, preview generators, and webhook testers all qualify. The allowlist you wrote to keep content in is also the list of doors that lead out.
Streaming output is a trust boundary
The race condition is not a Copilot quirk. It is structural to any interface that streams model output into a live page and sanitizes after the fact. The browser acts on markup the instant it arrives. A sanitizer that runs on the finished response is always one step behind a tag that triggers a network call on render.
Expect this class of bug in other products. Every assistant that renders streamed HTML and cleans it up at the end has the same gap until it moves sanitization to render time. When you review an AI feature, treat the streaming surface as untrusted output, the same way you treat user input.
What a SOC can actually hunt for
The hard part for defenders is that the endpoint sees almost nothing. No malware, no attachment, no second-stage download on the victim's machine. The only durable signal is the traffic.
- In proxy, CASB, or web-gateway logs, look for Copilot Search URLs whose
qparameter carries HTML tags or instructions to build an image URL out of mailbox content. - Watch egress to
bing.com/images/searchbyimagethat carries unusual encoded path segments, especially right after a Copilot session. - Correlate the two. A crafted Copilot Search request followed seconds later by an image-search call is the whole attack in two log lines.
This is a logs-and-egress hunt, not an EDR one. If your visibility into Microsoft 365 and outbound web traffic is thin, this attack would have run silently. The same lesson sat under Ivanti Sentry's post-patch breach: fixing the bug does not tell you whether someone already used it.
Do Microsoft 365 Copilot customers need to take action?
No patching is required. Microsoft mitigated SearchLeak on its own backend in early June 2026, the fix reached every tenant automatically, and Varonis found no in-the-wild abuse. The useful work now is forward-looking: log Copilot Search URLs, audit which allowlisted services perform server-side fetches, and add the two egress patterns above to your hunt rotation.
Classic bugs, new context
Server-side request forgery and HTML injection are old. Reachability is what changed. Prompt injection gave a remote attacker a way to drive privileged data into those old bugs from a first-party domain, and the AI feature supplied the permissions to make it pay. The next one will not be Copilot. It will be whichever product most recently bolted a language model onto data it was trusted to hold. SearchLeak is fixed; the pattern that produced it is not, and that is where MFA-code theft like this keeps coming from. It is the same auth-stack blind spot we flagged with Velvet Ant: the codes are only as safe as the system allowed to read them.