One Click. M365 Copilot Handed Over Everything.

TL;DR

– CVE-2026-42824, called SearchLeak, made Microsoft 365 Copilot Enterprise Search into a single-click siphon for MFA codes, inbox contents, meeting details, and private SharePoint and OneDrive files.
– Microsoft pushed a server-side patch and slapped their highest “critical” label on it. Except their CVSS score doesn’t match the National Vulnerability Database’s score. No customer action was needed for the fix itself.
– The exploit stacked three bugs: a URL-parameter-to-prompt injection, a browser rendering race condition, and a server-side request forgery that rode Bing’s own image-search to punch through Content Security Policy.
– LLMs can’t tell instructions from data. Nobody’s solved that. Another SearchLeak isn’t a question of if.

Click a Microsoft link. That’s it.

That’s the whole attack.

Varonis Threat Labs went public with the details. By then Microsoft had already pushed the server-side fix. No action on your end. Patched. Done.

Except it’s not done.

Not even close. The thing that made SearchLeak work. Large language models treating every string as a potential command. Doesn’t have a fix. Microsoft can’t ship one. Nobody can.

And honestly? If you’ve got M365 Copilot running in your org, someone’s probably already doodling the next variant on a whiteboard somewhere.

How three bugs became one click

Three weaknesses. Each one unlocked the next. Varonis described it as a “three-stage vulnerability chain” and tbh the design is almost artful. In a horrible way.

First: Parameter-to-Prompt injection.

The “q” parameter in a Copilot Enterprise Search URL? It’s supposed to hold a search query. Plain text a human typed. Microsoft fed that string straight into Copilot as a runnable prompt. No sanitization. No validation. So an attacker packs instructions and HTML into the q parameter of a legitimate Microsoft link. Victim clicks. Copilot reads those instructions and executes them. Rummaging through the victim’s mailbox, calendar, SharePoint, OneDrive. The victim never typed a word into Copilot. They clicked a link they trusted.

Second: a browser race condition. While Copilot streamed its answer back, the browser briefly painted raw HTML to the screen before the sanitizer could wrap it in code blocks. Tiny window. Fraction of a second. Long enough for a planted `` tag to fire off a request. That request URL?

It carried the stolen data baked right in.

Third: SSRF through Bing’s image search.

The `` tag pointed at Bing’s “Search by Image” endpoint. Explicitly allowlisted in the Content Security Policy because, well, it’s Bing. Bing then performed a server-side fetch to the attacker-controlled URL embedded in the image address. Data travels out. Attacker receives it. Bing didn’t know it was playing courier.

Classic SSRF. Sitting right there behind a CSP rule everyone trusted.

Victim clicks. Copilot searches their inbox, calendar, org files. Data lands on the attacker’s server. That’s the whole sequence.

Three moving parts, one click.

Why the CVSS fight matters more than you think

Microsoft called CVE-2026-42824 “critical.” Their top severity tier. Then they gave it a CVSS score.

NVD scored it higher.

Both say it’s serious. Neither agrees on how serious. And that gap isn’t just nerd drama.

CVSS numbers run patching priorities everywhere. In a lot of orgs, a lower score lands in “medium” and gets queued behind louder fires. A higher score trips SLA timers. Automates escalation. When Microsoft calls something their maximum critical but the number reads medium-ish, your tools and your risk register disagree. Things fall between.

If you’re a small shop without a security team?

Worse. You’re not cross-referencing NVD scores against MSRC advisories. You see “patched, no action required” and close the tab. Totally fair. For this specific CVE that actually worked out fine. But the scoring split tells you something bigger. The industry has no consistent way to rate AI-specific vulnerabilities yet. Injecting commands into a URL parameter that feeds an LLM isn’t the same animal as shell injection. The scoring models weren’t trained for this. (Side note: NVD’s whole scoring methodology hasn’t had a material update since CVSS v3.1 in 2019. They’re grading 2026 AI attacks with a rubric built for buffer overflows.)

Expect more disagreement. Expect more gaps where something falls through.

P2P injection isn’t regular prompt injection

You’ve seen the usual prompt injection playbook. Poison a document. Hide instructions in an email. Slip something into training data. The model reads it, follows it. Defense: sanitize inputs, filter outputs.

Parameter-to-Prompt is different.

The instructions aren’t in a file the model reads. They’re in the URL itself. Passed straight to the AI as an executable prompt. The victim doesn’t type. Doesn’t open Copilot. Clicks a link on a microsoft.com domain and the q parameter tells Copilot what to search, what to summarize, what to exfiltrate.

Your existing defenses don’t catch this. Input sanitization checks file uploads and text fields. It’s not watching URL parameters for hidden AI commands. CSP blocks traffic to unknown domains. But Bing’s image endpoint was allowlisted. It’s legitimate Microsoft infrastructure. Every trust layer in the stack got turned inward.

Dark Reading grouped SearchLeak with a growing cluster of AI prompt-injection attacks that smuggle instructions through URLs and other channels nobody monitors.

This is early.

It’s one of the first documented cases. Won’t be the last. Any input channel that feeds an LLM — URL params, API callbacks, webhooks, email headers, calendar invites. Is a potential injection surface. Most of them? Nobody’s watching.

Shrinking the blast radius before the next one

Patch is live.

No action required. Great. Fixes this chain. Doesn’t fix the problem.

The problem: Copilot Enterprise runs with your full Microsoft Graph permissions. Exploit the next variant and the attacker inherits everything the victim can reach. No separate auth needed. Your inbox is the rich target since it holds one-time passcodes, MFA tokens, password-reset links that stay valid for a short time. Calendar items leak meeting notes. SharePoint and OneDrive store comp data, salary tables, deal terms.

If I ran a small business on M365 Copilot right now, I’d do four things.

Tighten what Copilot can see. Varonis recommends pruning data-access governance so Copilot indexes fewer sensitive documents. Can’t steal MFA codes from an inbox Copilot can’t read. Restrict access to sensitive SharePoint sites. Pull back calendar visibility. Every permission you revoke from Copilot shrinks the damage radius of whatever comes next.

Watch for weird Copilot Search URLs. Flag URLs carrying HTML tags or encoded instructions in the q parameter. Set alerts for unusual outbound hits to Bing image endpoints. Varonis spotted these signals after the fact. They’ll catch future variants too.

Audit your CSP allowlists. Bing’s image-search was trusted by default and it became the escape tunnel. Go check what other Microsoft domains are allowlisted in your tenant. Each one is a potential proxy for the next attack.

Don’t mistake a patch for a cure. Microsoft closed this particular chain. They didn’t — couldn’t. Fix the fact that LLMs don’t distinguish instructions from data. The next Parameter-to-Prompt variant will find a distinct URL parameter. A separate race condition. Another trusted proxy. Guard against the class of attack, not just this one instance.

SearchLeak was a proof-of-concept. Nobody caught it in the wild. Cold comfort. The next person who pieces this together won’t write it up first. They’ll use it.