On December 31, 2025, security researchers at Varonis sent Microsoft a writeup of a bug in Microsoft Copilot that let a single clicked link silently pull data out of a user's connected Gmail, Google Drive, and Copilot's own conversational memory. Microsoft shipped a partial fix five weeks later, on February 1. The complete patch didn't land until August 18, 2026 — almost eight months after the initial report, and only a few days before this article was written.
That gap is worth sitting with, but it isn't the most interesting part of the story. The interesting part is how Varonis found the bug in the first place. They didn't fuzz an API or diff a JavaScript bundle. They opened a chat window with Copilot and asked it, repeatedly, to explain why the attack they were describing was supposedly impossible — and Copilot's refusals kept leaking the architectural details needed to build it anyway.
Varonis calls the technique "meta-hacking," and the resulting vulnerability chain is tracked as CVE-2026-24301, nicknamed CoSnitch.
What actually happened
CoSnitch affects Copilot Personal — the consumer-facing version of Copilot with memory and connected-app access — not Copilot for enterprise customers, who were unaffected throughout. The vulnerability let an attacker craft a URL that, when clicked, caused Copilot to execute an attacker-supplied prompt automatically, with no further interaction from the victim. Because the victim was already authenticated, that prompt ran inside their live session, with access to whatever accounts they'd connected: Gmail, Google Drive, and Copilot's own persistent memory of prior conversations.
Varonis says it found no evidence the bug was exploited before the fix shipped. That's the good news. The bad news, structurally, is that a consumer AI assistant with broad account access turned out to be reachable through nothing more than a link — the oldest attack primitive on the web, pointed at one of the newest attack surfaces.
How the meta-hacking technique actually worked
The mechanics, per Varonis researcher Lior Adar, are almost embarrassingly simple once you see them:
"At the beginning, Copilot kept refusing, but every refusal revealed technical details about its internal architecture. Copilot eventually disclosed undocumented parameters. I took those parameters and used them for prompts for running automatically."
Here's the shape of that conversation. Adar's team suspected Copilot's chat interface accepted URL parameters that could pre-populate or trigger a prompt — a common pattern for "share this conversation" or "deep link into a specific query" features. Instead of black-box testing every parameter combination, they asked Copilot directly: could a URL auto-run a prompt without the user pressing Enter? Copilot, behaving exactly as an assistant should when asked a technical question about itself, explained why that specific concern didn't apply — and in doing so, described the parameter design it was defending. Each "no, because X" answer was itself a specification leak. Reframe the refusal as a follow-up question, extract a bit more of the picture, repeat.
What that process eventually surfaced were two distinct URL parameters, both required together:
-
?q=— pre-fills Copilot's input box with attacker-supplied text, but still requires the victim to press Enter. -
?autorun=1— the undocumented parameter that skips that step and executes the prefilled prompt on page load, with zero further interaction.
Neither parameter alone was dangerous. ?q= without ?autorun=1 is just a convenience feature — arguably even a reasonable one for deep-linking into a specific query. It's the combination, plus an undocumented flag Microsoft apparently never intended external parties to discover, that turned a UX shortcut into a one-click account takeover primitive. A victim who clicked a booby-trapped link handed an attacker a live, authenticated, tool-using AI agent sitting on top of their Gmail and Drive.
Why "asking the model" is the actual news here
Prompt injection itself isn't new — it's the single most-discussed AI security category of the past two years, and every vendor shipping an agent with tool access has shipped some flavor of mitigation for it. What makes CoSnitch worth a longer look isn't the vulnerability class; it's the reconnaissance method.
Traditional API fuzzing assumes the target is silent — you send inputs and infer behavior from outputs, error codes, timing. Meta-hacking assumes the target talks back, in natural language, with the (reasonable, well-intentioned) goal of being maximally helpful and transparent about how it works. A refusal like "that can't happen because parameter X blocks it" is, from a security-research standpoint, indistinguishable from a spec leak. The model isn't malfunctioning. It's doing exactly what a helpful-and-harmless-tuned assistant is supposed to do: answer questions about itself accurately. That instinct is precisely what got weaponized.
This matters for anyone building on top of a model with system access, tool calls, or connected data — not just Microsoft. If your agent will explain its own guardrails when asked "why can't you do X," you've built a self-documenting attack surface. The fix isn't "make the model lie about its architecture" — that has its own obvious problems — it's recognizing that an assistant's explanations of its own limits are now part of your threat model, the same way verbose error messages or stack traces have been for twenty years of traditional appsec.
What changed versus the pre-agent era
Compare this to a hypothetical 2015-era version of the same underlying flaw: a web app with an undocumented autorun query parameter that skips a confirmation step. That's a real bug, but its blast radius is bounded by whatever that one app can do. CoSnitch's blast radius was bounded by whatever Copilot Personal's connected integrations could reach — which, by design, spans multiple third-party services via OAuth. The vulnerability lived in Microsoft's product, but the exploitable surface was the union of everything the user had connected to it.
That's the structural shift agentic AI products introduce: the attack surface is no longer just "this app's code," it's "this app's code, plus every scope it was granted across every service it's allowed to touch, minus whatever guardrails the model applies at inference time." Guardrails that live in a probabilistic model, reachable via natural-language social engineering of the model itself, are a fundamentally softer perimeter than a hard-coded permission check. CoSnitch is a clean demonstration of that gap, not a one-off implementation bug.
It's also a textbook instance of the "confused deputy" problem that predates AI by decades: a trusted intermediary (Copilot, authenticated as the user) gets tricked into using its own legitimate privileges on an attacker's behalf. What's new is the delivery mechanism. Classic confused-deputy attacks needed a crafted request against an API. This one needed a crafted <a href> — the exact same primitive that's powered email phishing since the 1990s, now aimed at a target with read/write access to a user's inbox, files, and AI-retained conversation history instead of just a session cookie. The web's oldest social-engineering vector turned out to compose just fine with its newest, most privileged client.
Practical takeaways for teams building agents
A few things are directly actionable if you're building or securing a product in this category:
- Audit every URL parameter your assistant's web interface accepts, especially anything that can pre-fill or trigger a prompt. If a parameter can move a conversation forward without a positive user action (a click, an Enter key), treat it as an auto-execution primitive and threat-model it accordingly — deep links should require confirmation, not skip it silently.
- Don't let "ask the model" be your only defense-in-depth layer. If your agent is asked to justify why an attack path is closed, its answer is potentially disclosing the mechanism of that closure. Consider whether architecture-sensitive questions should get a generic non-technical answer instead of a detailed one, the same way you wouldn't have a web server explain its own WAF rules to an unauthenticated caller.
- Scope connected-account access tightly and log deep-link entry points. The actual damage in CoSnitch came from OAuth-connected Gmail, Drive, and memory — not from Copilot's core chat function. Least-privilege scoping and separate audit logging for actions triggered via URL entry (versus in-session typing) would have limited blast radius even if the auto-run flaw existed.
- Time-to-patch matters more for agentic products than it used to. A traditional web vulnerability sits there until exploited. An AI assistant vulnerability sits there while the assistant itself is actively used, daily, by people who've granted it standing access to their inbox — the exposure window compounds differently.
What the disclosure leaves unanswered
Varonis's account, and Microsoft's response, both leave real gaps. There's no public accounting for why the fix took from February 1 (the partial patch, addressing auto-execution) to August 18 (the full fix) — over six additional months for what reads, based on the two-parameter combination described, like a contained and well-understood bug by the time the first patch shipped. Microsoft has said no customer action is required and that enterprise customers were never in scope, but hasn't published a detailed root-cause postmortem explaining the delay, which is the piece security teams evaluating vendor trust actually want.
It's also unclear whether ?autorun=1 was the only undocumented parameter of its kind, or whether the same meta-hacking approach — patiently interrogating Copilot's refusals — would surface others. Varonis's report demonstrates a method, not an exhaustive audit. Given that the method requires nothing more than a chat window and persistence, it's reasonable to assume other researchers (and less scrupulous actors) are already running the same play against Copilot and its competitors.
Competitive and industry context
Copilot isn't alone in offering an AI assistant with connected third-party accounts and URL-based entry points — ChatGPT's connectors and Gemini's extensions occupy the same product category: an agent with standing OAuth access to a user's email, files, and calendar, reachable through share links and deep links by design, because that's exactly the convenience feature users ask for. None of that makes CoSnitch a Microsoft-specific failure so much as an early, concrete instance of a risk the entire agentic-assistant category shares. The distinguishing fact here is the disclosure method, not the vulnerability's uniqueness — every vendor in this space that ships a "shareable prompt link" or "deep link into a conversation" feature has the same category of risk to rule out, and few have published a security review of what happens when the assistant itself is used as a reconnaissance tool against its own implementation.
An independent read
The framing in most coverage of CoSnitch — "AI assistant tricked into revealing its own architecture" — undersells what happened. Copilot wasn't tricked in the sense of being fed a jailbreak payload. It was asked ordinary, good-faith-sounding technical questions and it answered them competently and honestly. That's arguably the more uncomfortable finding: the failure mode didn't require adversarial prompting technique at all, just patience and the willingness to treat "why not" as a research question rather than a dead end. Any team currently red-teaming an agent by throwing jailbreak prompt libraries at it should add "ask it nicely to explain its own guardrails" to the checklist, because that's the technique that actually worked here.
The eight-month timeline is the other half of the story worth being skeptical about. Microsoft's messaging — no evidence of in-the-wild exploitation, enterprise unaffected, no customer action needed — is all defensible and probably accurate, but it's also the standard vendor script regardless of how long a fix actually took. A bug that combines "one click," "no user interaction required," and "access to email plus files plus AI memory" sitting partially unpatched for over half a year is a genuinely long window for a vulnerability class this severe, and the absence of a published root-cause explanation for that gap is the part of this disclosure that deserves more scrutiny than it's gotten so far.
Who should act on this
Copilot Personal users don't need to do anything — the fix is deployed, and Microsoft has stated no customer action is required. If you're security-conscious, it's still worth reviewing what your Copilot instance has OAuth access to and pruning anything you don't actively use.
Teams building AI agents with connected-account access or deep-link/URL-triggered prompts should treat this as a direct action item, not background reading: audit your own URL parameter surface for anything resembling autorun-style behavior, and consider whether your agent's own explanations of its guardrails could function as a specification leak under sustained, patient questioning.
Security researchers and red-teamers working on agentic AI products have a new technique worth adding to standard toolkits — meta-hacking is cheap, requires no special tooling beyond a chat window and patience, and this disclosure is a working proof that it finds real, high-severity bugs that conventional testing missed for months. It also composes naturally with existing prompt-injection test suites: instead of only throwing adversarial payloads at a model, spend a session asking it plain questions about its own limits, log every answer, and look for anything that reads like a spec rather than a policy.
Product and platform teams shipping "connect your account" AI features — a category that now includes most major assistants — have a narrower but sharper lesson: any deep-link or share-link feature is a URL-based entry point into an authenticated session by construction, and it deserves the same scrutiny as an OAuth callback endpoint, not the lighter review a "convenience UX feature" typically gets internally.
Everyone else can safely treat this as informative rather than urgent — but it's a useful data point the next time a product pitches "connect your inbox to our AI assistant" as a frictionless convenience feature.
What's your take: does patiently interrogating a model's own refusals count as a security research technique teams should be red-teaming for proactively, or is this closer to a one-off quirk of how Copilot's guardrails happened to be implemented?
Sources:
- CoSnitch: When Your AI Assistant Becomes Its Own Whistleblower
- 'CoSnitch' Attack Tricked Copilot into Revealing Own Architecture
- Microsoft Copilot Personal Flaws Could Let One Click Exfiltrate Data From Connected Apps
- Microsoft finally patches critical one-click Copilot vulnerability, almost eight months after learning of it — CSO Online
- Copilot tricked into telling researchers how to hack itself — The Register
- Microsoft finally patches critical one-click Copilot vulnerability — Computerworld
Top comments (0)