Microsoft 365 Copilot has been found vulnerable to a one-click attack that could expose sensitive user data, after researchers at Varonis discovered an undocumented input parameter by asking the AI assistant itself. The result is an unusual security story: the model not only helped reveal the flaw, but also enabled an exploit that could run without the user providing any explicit confirmation.
How Microsoft Copilot revealed the flaw
Varonis researchers said they wanted to build an exploit that would exfiltrate data after nothing more than a click on a link. Copilot, like many AI assistants, resisted requests that would bypass user approval and repeatedly said sensitive actions needed a gesture such as pressing Enter or another key.
Instead of stopping there, the researchers kept questioning Copilot about its safety rules. With each refusal, Copilot exposed more detail about how its guardrails worked, including URL structures, deep links and what happened when a page loaded with text already in the prompt field. Eventually, Copilot disclosed what Varonis described as an undocumented prompt parameter that bypassed the consent requirement entirely.
The secret input: ?autorun=1
The parameter was ?autorun=1. Used together with the better-known ?q= parameter, it allowed a prompt to execute automatically when the target clicked the malicious link. Varonis senior researcher Lior Adar told Ars that Copilot’s refusals “revealed technical details about its internal architecture” and eventually exposed the undocumented parameter that made automatic execution possible.
Microsoft had already quietly mitigated part of the issue in February, three months after Varonis reported it, by preventing ?q= from injecting text directly into the chatbot input. That change forced the user to click and type manually, which also prevented third-party browser integrations from using the parameter as originally intended. Microsoft introduced more comprehensive fixes on Tuesday, according to the report.
What the Microsoft Copilot attack could do
Once the researchers had the parameter combination, they could craft a link that looked harmless but executed a prompt in the recipient’s authenticated Copilot session. Varonis said the attack could be delivered through email, chat, phishing pages or even a QR code.
One example prompt asked Copilot to search the inbox, find the latest email, extract only the sender’s email address, and place that address into a variable. The prompt then built a URL pointing to an attacker-controlled webhook, effectively sending the data to a server outside the victim’s environment.
- The victim clicks a crafted URL.
- The browser loads copilot.microsoft.com in the active authenticated session.
?autorun=1triggers automatic execution and?q=fires without a user gesture.- Copilot processes the prompt with access to session context, connected apps and memory.
- The prompt runs to completion, even if the Copilot tab is closed immediately.
Varonis said a similar prompt could search for passwords or other credentials previously sent to the user’s address, then leak any discovered secrets to the attacker-controlled endpoint. To make transmission more reliable and less obvious, the stolen data was converted to base64 before being sent.
Why the issue mattered beyond inbox data
The attack was not limited to one type of content. Because Copilot could act within the user’s session context, the researchers said the same technique could invoke connected apps and follow multi-turn prompt chains. That broadened the risk beyond a single mailbox query and into the kinds of actions modern AI assistants are increasingly expected to handle.
Varonis also said the prompt would continue executing even if the Copilot tab was closed right after loading. That detail makes the attack especially concerning, since a user could believe they had interrupted it while the assistant had already begun processing the malicious request.
Prompt injection and Copilot’s persistent memory
Beyond the exfiltration issue, Varonis said it found another attack path that used prompt injection embedded in a webpage to poison Copilot’s permanent memory store. That memory is used to store user information, preferences and instructions so the assistant can recall them in future sessions without needing the user to repeat them.
When a user asked Copilot to summarize the page, the assistant could follow hidden instructions in the page metadata and update its memory. According to Varonis, that could be used to forward outputs, filter information, bias responses toward attacker-chosen narratives or trigger attacker-defined actions under specific conditions.
The company also said those false memories would persist across password changes, session revocations and device re-enrollments. The only way for a user to spot the problem would be to manually inspect the memory contents.
Co-Snitch, SearchLeak and a familiar pattern
Varonis has named this set of attacks Co-Snitch. The firm said it follows earlier work against Copilot Personal, which also required only a single click to launch a covert, multistage attack. In June, Varonis demonstrated another one-click exfiltration attack called SearchLeak.
The pattern is familiar in AI security: researchers find that guardrails meant to prevent harmful behavior can often be bypassed, especially when the system is persuaded to reveal how those guardrails are built. In this case, the assistant itself exposed the raw ingredients needed to compromise it.
What users should take away
The broader lesson is not that every AI assistant is broken, but that users should treat AI-driven links and prompts with the same caution they would apply to any suspicious message. A single click on an untrusted link can still trigger actions that are not obvious from the page or the URL.
Practical defenses remain basic but important:
- Avoid clicking links in emails, chats and webpages you do not trust.
- Watch for unexpected behavior or unusual outputs from AI assistants.
- Limit the number of connected apps and permissions available to AI tools.
- Review memory or personalization settings when available.
Varonis’ findings also highlight a deeper problem for LLM security: many protections are reactive rather than preventive. They are designed to reduce damage after something goes wrong, not always to stop a malicious workflow from starting in the first place. As this case shows, those guardrails can fail in ways that are both technical and ironic.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: August 19, 2026 at 1:51 am
6 views
