CoSnitch: What the Copilot Security Flaw Reveals About Off-the-Shelf AI Tools

A click on a crafted link. That's all it took for Microsoft's AI assistant Copilot to send complete email content, calendar entries, file metadata, and full chat history to a stranger's server - without anything in the network traffic looking suspicious. The flaw is called CoSnitch, officially tracked as CVE-2026-24301, and it's notable because Copilot essentially gave the researchers the way in itself. For companies weighing whether an off-the-shelf AI tool is the right choice, this case is worth a close look - not because of the headline, but because of the pattern behind it.

At first glance, the incident is a technical footnote from the IT security world. Look again, and it's a case study in what happens when a single software product has to serve a very broad, heterogeneous user base with wildly different requirements at once - and in doing so inevitably accumulates so many features, interfaces, and edge cases that no one keeps the full attack surface in their head anymore. This tension between reach and overview is at the center of this article.

What exactly happened

Microsoft officially classifies CVE-2026-24301 as a "Microsoft Copilot Information Disclosure Vulnerability" and technically categorizes it as command injection - specifically, improper neutralization of special characters in a command. The CVSS score is 8.8, in the critical range. It was discovered by the Varonis Threat Labs, specifically researcher Lior Adar, who reported it to Microsoft in December 2025. The patch followed on August 18, 2026 - roughly eight months after the report, rolled out server-side without users needing to install anything themselves.

Eight months between report and patch sounds like a long time at first. For a product of this scale, though, that's a realistic timeframe for so-called responsible disclosure: the reporting researcher keeps the flaw confidential, the company analyzes it, develops a fix, tests it against every existing feature, and rolls it out in a controlled way without breaking other parts of the system. This complexity - many parallel use cases, numerous connected services, countless feature combinations - is the real thread running through this story.

Important context before we get into the details: according to The Hacker News, CoSnitch primarily affected Microsoft Copilot Personal - the consumer product at copilot.microsoft.com with OAuth connections to private services like Gmail, Google Drive, and Google Calendar. Not directly affected, according to this source, was Microsoft 365 Copilot, the business product connected to Outlook, SharePoint, and OneDrive that many mid-sized businesses use in daily operations. Anyone citing CoSnitch uncritically as proof that business AI is insecure is making it too easy for themselves. Why that's still no reason for reassurance about enterprise use becomes clear further below.

The anatomy of a three-stage attack

What makes the case technically interesting is the chaining of three individually harmless building blocks into a working attack. First: an undocumented URL parameter called "autorun=1" that, combined with the regular search parameter "q=", automatically executed a prompt when the page loaded - with no further confirmation from the user at all. Anyone who clicked a link with this parameter unknowingly triggered an action in their own Copilot account, without ever clicking "send" or "confirm."

Second: the actual data exfiltration ran through already-connected services. Because Copilot Personal was linked via OAuth to Gmail, Google Drive, and Google Calendar, the automatically executed prompt could access complete email content, calendar entries, file metadata, and full chat history. This data was base64-encoded, appended to URLs, and sent via Copilot's own web-summarization feature to webhooks controlled by the attacker. The trick: to the network, this looked like a perfectly normal HTTPS GET request, the kind that occurs constantly when loading and summarizing a webpage. According to Varonis, the attack generated "no anomalous signals" - classic detection mechanisms had nothing to catch, because there was simply nothing that looked like an attack.

Third, and this is what makes the attack particularly persistent: via crafted external websites, indirect prompt injection - triggered by the URL summarization feature - could write a permanent entry into Copilot's personal memory store. Such an entry survived password changes, revoking active sessions, and re-registering devices. Anyone once affected couldn't get rid of the compromise with the usual immediate measures - the standard post-incident checklist simply didn't work here.

A single click was enough for full compromise - and the attack left no anomalous signals in network traffic that would have stood out in the classic way.

Meta-hacking: how Copilot gave itself away

The most unusual part of the story is how the flaw was even found. The researchers at Varonis didn't primarily throw technical exploit attempts at Copilot - they repeatedly asked it simple questions about its own security guardrails and why certain requests were being rejected. In the middle of one such rejection, Copilot practically volunteered an explanation of the undocumented URL parameter, its earlier behavior, and every safeguard built against it. The AI itself gave away the way to bypass it - hence the name CoSnitch, derived from "snitch," slang for an informant.

This "meta-hacking" - mapping a system by asking the system itself targeted questions - only works with assistants that carry so much internal knowledge about their own architecture, exception rules, and historical behaviors that they'll disclose it if you ask cleverly enough. That's precisely the flip side of a product developed over years for many very different use cases at once: it accumulates edge cases, legacy baggage, and documented as well as undocumented exceptions, until the system itself becomes an information source for attackers - a system, in effect, that comments on its own attack surface if you just ask long enough.

No isolated case: Reprompt, SearchLeak - and the Personal versus Enterprise question

CoSnitch is already the third Copilot vulnerability uncovered by Varonis this year. In January 2026, "Reprompt" was disclosed and patched on January 13, 2026 - also in Copilot Personal, with a similar one-click pattern for silently harvesting personal data. In early August 2026, "SearchLeak" (CVE-2026-42824) followed, this time in Microsoft 365 Copilot Enterprise, i.e. the business product. SearchLeak allowed, among other things, reading two-factor codes, emails, and SharePoint and OneDrive files, and was also rated critical.

Three structurally similar flaws within a few months, discovered by the same research team, are no coincidence and no series of unrelated individual bugs. They show a recurring pattern: a single link or URL parameter is enough to get an AI with already-existing, authorized connections - OAuth connectors to email, calendar, storage services - to silently harvest data. The attack surface doesn't arise from a single coding mistake, but from the interplay of broad, pre-configured access rights and features originally designed for convenience - automatic prompt execution, automatic web summarization, persistent memory across sessions.

That's also why the distinction between Copilot Personal and Microsoft 365 Copilot Enterprise is important, but not reassuring. CoSnitch itself primarily hit the consumer product. But SearchLeak, the second flaw from the same research line, explicitly affected the enterprise variant with access to two-factor codes, emails, and corporate file storage - showing that the same structural pattern also occurs where businesses store their most sensitive data. The relevant lesson, then, isn't "Copilot Personal is insecure, M365 Copilot is safe," but: broadly connected, feature-rich AI assistants with many connectors carry a structural risk regardless of whether it's the consumer or the business variant.

What this says structurally about off-the-shelf AI tools

The real core of this story isn't the individual security flaw, but what its origin reveals about how generic AI assistants are built. A product developed for a very broad and heterogeneous user base with many different use cases at once inevitably accumulates features: automatic prompt execution for convenience, web summarization for research, persistent memory for continuity across sessions, broad OAuth connections for reach. Each of these features makes sense on its own and is understandable from a product perspective. In sum, though, they create an attack surface so large and so intertwined that even the developing company itself could only fully map it through laborious, iterative questioning of its own system.

For a lean, purpose-built agent with a clearly defined task scope, the question looks different. An agent that, say, only checks invoices or answers scheduling requests doesn't need an undocumented auto-run parameter, a general web-summarization feature for arbitrary third-party pages, or persistent, cross-session memory for arbitrary external input. It naturally has a smaller, more manageable attack surface - not because it was built by fundamentally better developers, but because it structurally carries fewer features and fewer hidden edge cases that first have to be laboriously discovered before they can be exploited.

That's no guarantee against every conceivable security flaw - custom software can contain bugs too, and no one should sell custom development as automatically immune to attacks. But it is a difference in baseline risk: a system with fewer features, fewer connectors, and a clearly bounded access scope simply has fewer places where attack chains like CoSnitch's can even come together. Fewer moving parts mean fewer combinations someone first has to find and then exploit.

What you should check right now

Regardless of whether your company uses Copilot, another off-the-shelf AI assistant, or already runs its own agents, the CoSnitch case yields concrete, cross-product recommendations that can be implemented with little effort:

Regularly review connected apps. Periodically check which OAuth connections and connector apps your AI assistant actually has, and cut any that are no longer actively needed. Every additional connection is an additional potential attack path, even if it practically never becomes a problem in day-to-day use.

Treat AI assistants like privileged insiders. An assistant with access to email, calendar, and file storage effectively has rights similar to an employee with broad access. Its access pattern should be monitored accordingly - no differently than you would with any new, far-reaching system access.

Be careful with links containing pre-filled prompts. URLs containing parameters like "?q=" that already carry a prompt with them deserve special attention. This exact pattern was the starting point for CoSnitch, and it's easy to cover in staff training.

Take unusual automatic actions seriously. If an AI assistant unexpectedly fetches URLs or produces output that doesn't match the task at hand, that's a warning sign that shouldn't be ignored - even if it looks harmless at first glance.

None of these four measures requires its own security team or a big budget. Above all, they require one thing: the conscious decision not to treat AI assistants as a mere convenience tool, but as what they technically actually are - a system with far-reaching access to business-critical data that should be handled accordingly. Anyone who works through these four points once and then anchors them as a fixed calendar appointment has already covered a large part of the risk that cases like CoSnitch structurally expose.

Important for context: Varonis found no evidence that CoSnitch was actively exploited before the patch. This was a responsibly reported and promptly closed flaw, not a known damage case. That takes nothing away from its relevance - on the contrary, it shows that a working responsible-disclosure process can deliver exactly what it's meant to, as long as someone with the necessary time is looking.

In the end, CoSnitch isn't a story about a single faulty parameter, but about how generic AI assistants are built to cover as many use cases as possible at once. Automatic prompt execution, broad OAuth connections, persistent memory, and web summarization are useful features on their own - together, they create an attack surface so complex that even the manufacturer only saw it fully through systematically questioning its own system. Reprompt, SearchLeak, and CoSnitch show the same pattern in three variations within a few months. For companies weighing how to use AI productively and responsibly at the same time, it's therefore worth asking whether the broadest possible tool is really the best choice - or whether a lean, purpose-built agent with clearly limited access offers the more robust foundation from the start.