SearchLeak: How a Link Turned Microsoft 365 Copilot into a Data Leak

6 min. read

A single click on a crafted link was enough to make Microsoft 365 Copilot leak emails, calendar entries, and even one-time codes for multi-factor authentication to the outside world. The vulnerability, dubbed “SearchLeak” by its discoverers at Varonis Threat Labs and tracked as CVE-2026-42824 with Microsoft’s highest severity rating, started with a parameter injection: a manipulated URL value that secretly fed instructions to the assistant. Microsoft patched the flaw server-side in early June, requiring no action from users. The underlying problem, however, remains on the table. This attack vector is open to AI assistants that combine broad search access to corporate data with sloppy output and egress controls.

Key Takeaways

One click was enough. SearchLeak (CVE-2026-42824) turned Microsoft 365 Copilot into a data exfiltration tool via a crafted link, leaking everything from emails to one-time codes. Discovered by Varonis, with no evidence of in-the-wild exploitation.
Three flaws chained together. A parameter injection slipped in instructions, a rendering gap triggered them, and a server-side request smuggled the data past security mechanisms.
The patch doesn’t fix the class. Microsoft closed SearchLeak, but any assistant with broad data access remains a target. The solution lies in permissions, egress controls, and logging.

How a Link Becomes a Data Leak

SearchLeak relied on a chain of three vulnerabilities that only became dangerous when combined. It started with parameter injection: by manipulating the search parameter in the URL, attackers could slip a snippet of text to Copilot that the assistant treated not as user input, but as a command. A harmless link thus became a covert instruction.

The second piece was a timing gap during the response page’s rendering. An image element injected by the attacker loaded before the output was fully sanitized. The third component leveraged a server-side request through a Bing service, smuggling the harvested data past the page’s Content Security Policy. The result? One click, and content from the company’s Copilot searches slipped out unnoticed-ranging from email bodies containing credentials to calendar details and documents.

What makes this chain dangerous is its stealth. Each link on its own appears harmless: a search parameter is routine, a dynamically loading image is commonplace, and a request to a Microsoft-owned service is expected. Only the chaining of these elements creates an exfiltration path that requires no malware, no attachments, and no second user action. To the victim, the process looked like a standard Copilot response, while the data was already en route in the background. This exact camouflage explains why traditional defenses miss the attack: there’s no suspicious file for an antivirus to catch, and no obviously malicious sender for a spam filter to flag.

Why the Fix Doesn’t Solve the Core Problem

Varonis reported the chain to Microsoft, published a proof of concept, and found no evidence of exploitation in the field at the time of disclosure. Microsoft mitigated SearchLeak server-side at the beginning of June. For affected companies, this means: no client patch, no user action needed, the immediate danger is gone.

But this relief is misleading if read as an endpoint. SearchLeak is an example of an entire class of attacks where an AI assistant with broad access to corporate data becomes a lever. A hijacked assistant can reach everything the logged-in user has access to, and exactly this scope can be abused. Similar findings are foreseeable as long as assistants retain this broad access.

The core of the problem lies in the trust model. Copilot Enterprise Search is deliberately designed to access the user’s entire data set on their behalf, across mailboxes, calendars, SharePoint, and OneDrive. That is its value and simultaneously its attack surface. Whoever leads the assistant to take action acts with its rights, and those rights are extensive. Parameter and prompt injection are not exotic tricks but the logical consequence of the fact that the same input for the machine can be both content and instruction. As long as this boundary remains unclear, the attack class persists, regardless of how cleanly a single finding is closed. This shifts the task from hunting for individual vulnerabilities to asking how much damage a misused assistant could actually cause in a real-world scenario.

What Security Teams Should Harden Now

The sensible response is not to turn off Copilot, but to minimize potential damage should the next vulnerability appear. Four levers are crucial for this.

Restrict permissions tightly. Copilot Enterprise Search inherits the user’s access rights. Those who clean up generously shared folders and orphaned permissions reduce the radius a hijacked assistant can even reach. This is the most effective and frequently neglected measure. In practice, this means systematically reviewing overly broad SharePoint and OneDrive shares, open “Everyone in the Company” links, and leftover permissions from completed projects. The less an average account is allowed to see, the smaller the damage will be if exactly this account is misused via the assistant. The principle is not new; Copilot simply gives it an immediate lever.

Monitor data egress. SearchLeak exfiltrated data through an external service. Egress control and data loss prevention tools that detect unusual outbound traffic from the Microsoft 365 environment address precisely this last link in the chain. Microsoft Purview Data Loss Prevention and Defender for Cloud Apps can be configured to flag or block sensitive content when it leaves, even if the exit route goes through what appears to be a harmless image or service call. What matters is that the rules capture not only email attachments and obvious uploads but also the subtle channels such an attack uses.

Log assistant activity. Those who do not record which content Copilot accesses and which external targets it contacts will only notice such an exfiltration once it has caused damage. Logging AI interactions should be treated on par with logging privileged access. The Microsoft 365 audit log and Purview capture Copilot activities, provided logging is enabled and regularly reviewed. Without this review, incidents remain invisible until they are noticed elsewhere, and then the trail is already lost, making it impossible to reconstruct the full extent.

Treat AI links as attack surfaces. A link that controls an assistant is more dangerous than a classic phishing link because it accesses the user’s data on their behalf. Awareness programs should name this new vector rather than just warn against fake login pages. Employees have learned over the years to recognize suspicious senders and forged login screens. A link pointing internally to a familiar Microsoft tool slips through this filter because it looks neither foreign nor fake. Training must convey the difference: even a seemingly harmless link can move an assistant to perform actions the user never intended.

Frequently Asked Questions

What exactly is SearchLeak?

SearchLeak is a vulnerability discovered by Varonis Threat Labs in the Enterprise Search of Microsoft 365 Copilot, reported as CVE-2026-42824 with Microsoft’s highest severity rating. By using a prepared link, data could be extracted from Copilot search with a single click, including emails, calendar entries, documents, and one-time codes.

What does parameter injection mean in this case?

An attacker inserted text via the search parameter in the URL, which Copilot processed as an instruction rather than a search query. This allowed the assistant to be controlled without the user doing anything other than clicking a link.

Do I need to do anything as a Microsoft 365 customer?

No action is required for this specific vulnerability. Microsoft has patched it server-side in early June, so no client update or user action is necessary. Nonetheless, it is advisable to review Copilot permissions and monitoring, as the attack vector remains.

Was the vulnerability actively exploited?

Varonis reports that no signs of exploitation in the field were found at the time of disclosure. A proof-of-concept was published, but there was no indication of a real attack. This provides some reassurance retrospectively, but says nothing about future discoveries of the same type.

What lesson can a security team take from this?

That the security of a AI assistant depends on its data access. Tight permissions, egress control, logging of assistant activity, and awareness of AI-driven links limit damage when the next vulnerability of this class appears.