
Zero-Click RCE in MCP
Lakera researchers demonstrate a zero-click exploit chain against Cursor IDE configured with a Google Docs MCP server: an attacker silently shares a malicious document via the Google Docs API, which Cursor's agent retrieves and treats as trusted context, leading to prompt injection that abuses Cursor's command allow-list to achieve persistent remote code execution and credential/data exfiltration. The attack requires no victim interaction and exploits intended MCP/agentic IDE functionality rather than a patchable bug, showing that even "safe" MCP servers become dangerous when combined with implicit trust in external data and permission-fatigue-driven allow-listing.
What it is
Lakera's writeup of a zero-click exploit chain against Cursor IDE running a "safe" Google Docs MCP server. The summary already covers the shape of the attack; the page adds a few specifics an engineer acting on this would want, and a defensive framing. Note: the fetched text is truncated at "How the Exploit Works" — the detailed chain and any mitigations beyond the takeaway are not in what was retrieved.
How it works — the specifics beyond the summary
Two mechanics the page states concretely:
- Allow-list generalization is the pivot. Cursor prompts before running terminal commands by default, but developers commonly add interpreters to the allow-list to escape permission fatigue. The trap: allow-listing one Python script "automatically allows all Python code execution." Once Python is on the list, Cursor never asks again — so injected instructions that shell out to Python run silently.
- Silent sharing gives no signal. Via the Google Docs API, an attacker shares documents (titles like "Latest Project Specifications", "Technical Requirements", "Meeting Notes") and the recipient gets no notification. The docs are immediately searchable/retrievable — not just through the MCP, but through other Google tooling such as Gemini. So the malicious content is reachable through more than one integration, and blends in with legitimate org files.
Preconditions / Affected
- Cursor with a Google Docs MCP integration installed.
- An interpreter (e.g. Python) added to Cursor's command allow-list.
- Attacker holds a Google Docs account able to share into the target org (no membership implied — sharing is inbound and silent).
- Not a patchable bug: the page stresses this exploits intended MCP/agentic-IDE behavior, so there is no version to wait on.
What to do
The page offers no patch or commands, but its stated posture implies concrete action:
- Treat any external data entering an LLM or agentic workflow as untrusted input and validate it — the explicit key takeaway.
- Reconsider allow-listing interpreters in Cursor; understand that allow-listing one script authorizes all execution for that interpreter.
- For detection, remember silently shared docs surface with no notification and are reachable via Gemini as well as the MCP — auditing shared-document inflow, not just IDE logs, matters.
Caveats
- The retrieved text cuts off partway through "How the Exploit Works," so the concrete injection payload, the persistence mechanism, and the exfiltration path are not present here — read the source for those.
- The claim that "a secure MCP does not guarantee secure MCP interactions" is Lakera's framing; they note the MCP server itself is not the vulnerable component.
Technologies named here
- Cursor
- Google Docs MCP server
- Model Context Protocol
- Google Docs / Google Workspace sharing
- GitHub Gist
- Lakera Guard
- Google Docs
Techniques named here
- Stage Capabilities
- Phishing via Service
- Ingress Tool Transfer
- Command and Scripting Interpreter
- Boot or Logon Initialization Scripts
- Credentials in Files
- Private Keys
- Data from Local System
- Command and Control
- Exfiltration
- Prompt Injection
Related in Offensive Security