Microsoft logo at office building showing Microsoft CoPilot AI assistant

Researchers Sweet-Talk Microsoft Copilot Into Stealing Data

Researchers with Varonis have disclosed a flaw they call “CoSnitch“, a prompt injection that exfiltrates information from connected Google Drive accounts. The issue is not a breach, but rather an oversight that had allowed Microsoft Copilot to be tricked into giving up private information while being pressed to explain the technical reasons for not being able to execute a particular prompt.

The flaw was patched prior to publication earlier this month, but Varonis indicates it was first discovered all the way back in December 2025. Nevertheless, Varonis and Microsoft say there is no indication that it was ever exploited in the wild. It also appears to only impact the “Personal” or most commonly used version of Microsoft Copilot, and not the specialized Microsoft 365 Copilot used by businesses.

“CoSnitch” harangues Microsoft Copilot into sharing private Google and Microsoft account data

The attack centers on the fact that Microsoft Copilot (along with numerous other AI agents) is often trusted with permission to access the contents of otherwise private Google and Microsoft accounts, everything from stored files and calendar items to emails and chats. This is combined with the fact that use of certain parameters will cause Copilot to execute prompts it encounters on web pages instantly with no authorization from (or even warning to) the end user, making it possible to exploit a victim by simply sending them a malicious link leading to a seemingly innocuous page that hides a malicious prompt in the background. That second part was supposed to be kept private, but the researchers were able to massage Copilot into giving up this information.

The exploit is essentially a case of asking Microsoft Copilot “but why” over and over again like a child. In this case, it begins with asking the LLM how to execute a prompt automatically without user interaction. When Copilot rejects this idea, informing the user that prompts are not handled in that way, the attacker asks a follow-up question with a technical justification. A chain of such questions is navigated to map out the architecture that Copilot has access to. Eventually, deep enough in this chain, Copilot disclosed an undocumented URL parameter that included its historical behavior and every protection put in place to disable it.

The attack crafted from this would require the target to click on a malicious URL sent by the threat actor. However, it would be coming from the Microsoft Copilot domain and appear legitimate. This gives the attacker access to the user’s Copilot ecosystem as if they were the user themselves. Numerous malicious possibilities unfold from here: stealing data from email or cloud storage accounts via OAuth connectors, writing instructions into the user’s cross-session memory store, and modifying what Copilot surfaces to the user in future sessions among others.

The OAuth access is a particularly dangerous element as it allows Microsoft Copilot full read access to a connected Gmail account, including full message bodies. Similar access, authorized to Copilot by the users themselves, can be available to Google Drive files and Calendar items. The researchers found that Copilot could be instructed from this point to search Gmail accounts for credentials or anything labeled as internal; access to Copilot chat histories could also be abused in a similar way, up to providing a full dump of Copilot’s memory to the attacker.

Multiple Microsoft Copilot bugs now uncovered

Microsoft Copilot was patched on August 18, just a little ahead of the public disclosure of the vulnerability, and the trick to cause a parameter to automatically execute no longer works. Microsoft says that users are safe and do not need to take any action in response, though it has been assigned a CVE number (CVE-2026-24301) with a severity rating of 8.8. The fix also initially broke some third-party browser integrations that used the parameter in a legitimate way, which the company has since released fixes for.

The researchers note that while this only impacted the “Personal” edition of Microsoft Copilot, enterprise users often link these personal accounts to enterprise data through a variety of their own personal email and storage accounts. And in terms of network defense, any data exfiltration appears to be the normal fetches Copilot performs when it creates a summary of a web page.

The researchers call the technique “meta-hacking,” and its applications are not limited to just one AI. Varonis has made something of a cottage industry of finding these sorts of bugs in Microsoft Copilot as of late; this is the third they have published this year, with the others also involving simply manipulating the LLM into some sort of vulnerability and then passing a link to the tainted prompt. But the team also recently published a similar attack on Atlassian’s Rovo assistant.

As Anar Bayramov, Head of Product at Polygraf AI, notes: “Varonis found this in their Reprompt research, then in RovoBlast against Atlassian’s Rovo, and now in Copilot Personal. Same idea every time: let a URL parameter seed the assistant’s prompt because it’s convenient for sharing. Once that parameter can execute inside a logged-in session, you’ve got CSRF with an LLM’s permissions. What’s more interesting is the memory. Microsoft addressed this attack class in June – sanitization on write, Task Adherence checks, memory updates surfaced in Defender, and scoped all of it to Microsoft 365. The consumer assistant, where an injected instruction survives password changes and session revocation without leaving a log entry, wasn’t covered by that guidance. The controls exist, but they just weren’t described for the product where this landed.”

Centrally hosted LLM security continues to rely on developer guardrails for safety, and the researchers note that the pace of development and deployment is far ahead of defense at this point. However, this should not mean ceasing use of Microsoft Copilot or any other AI agents. The developers instead recommend regular audits of what these agents have access to, applying additional scrutiny to AI assistant URLs coming from an external source, and verifying that current tooling is set up to detect anomalous patterns of this sort from AI agents. User training also includes inspection of URLs for pre-filled prompts, and only keeping services that are actively being used connected to AI.