Abstract overhead

CursorJack: weaponizing Deeplinks to exploit Cursor IDE

Share with your network!

Author’s Note: This post reflects Proofpoint Threat Research observations in a controlled test environment as of January 19, 2026. Proofpoint has no commercial, customer, partner, or vendor relationship with Cursor (published by Anysphere, Inc.). Cursor did not review or endorse this report. We notified Cursor through its vulnerability‑reporting channel; the report was closed as out‑of‑scope / Not Applicable under their policy. Findings are presented as a risk pattern involving deeplink‑driven installation flows and social engineering and may evolve as vendors update features. Configurations and results may vary based on OS, user permissions, enterprise controls, and product versions; readers should apply multi‑layered controls and follow vendor guidance. 

Overview 

Cursor implements deeplinks for Model Context Protocol (MCP) to provide a mechanism for installation of MCP servers in Cursor IDE. This blog describes CursorJack, a method of potentially abusing Cursor MCP deeplinks that, under certain conditions, could enable code execution or allow installation of a malicious remote MCP server. The behavior described below is specific to the test environments noted and does not imply silent or zero‑click exploitation by default. It does, however, highlight the urgent need to secure agentic AI environments. 

Key takeaways 

  • The cursor:// protocol handler could be abused through social engineering in specific configurations. 
  • In our tests, a single click followed by user acceptance of an install prompt could result in arbitrary command execution. 
  • The technique could be leveraged both for local code execution via the command parameter or to install a malicious remote MCP server via the URL parameter. 
  • There is currently no visual distinction between a malicious MCP install deeplink and a legitimate one in the default UI flows we observed. 
  • Developers are potentially high-value targets as their workstations may have privileged accounts or contain credentials, API keys, source code and other sensitive data. 
  • Our POC code is available on GitHub

Cursor MCP Deeplinks 

Deeplinks are custom URL schemes to direct users to specific pages within an app. Cursor IDE implements MCP deeplink for quick installation of MCP servers with the following structure: 

cursor://anysphere.cursor-deeplink/mcp/install?name=<name>&config=<base64>

Figure 1

Figure 1. Deeplink schema (source: https://cursor.com/docs/context/mcp/install-links ). 
 

The MCP server configuration is base64-encoded within the deeplink URL. 

When Cursor is installed, the application registers the cursor:// protocol handler with the operating system. Once registered, any cursor:// link clicked launches Cursor and passes the full URL to the executable. In our tests, we did not alter OS URL‑handler protections or bypass interactive prompts. 

Figure 2

Figure 2. Cursor protocol handler. 

MCP.json  

The mcp.json configuration format has emerged as a standard for clients to declare how MCP servers should be launched or connected to. Within the ‘mcpServers’ object, each server entry defines its setup, including fields such as command, arguments, environment variables, or a url. 

Figure 3

Figure 3. mcp.json configuration format. 

MCP servers commonly specify a command and arguments in their configuration. Examples include npx, uvx, and docker, though this key can be used to pass any valid command. 

Figure 4

Figure 4. Example command-based MCP. 

Alternatively, MCP servers may define a URL in their configuration which could point to either a remote or local MCP server, functioning similarly to an API. 

Figure 5

Figure 5. Example of URL-based MCP. 

Abuse preconditions observed (high‑level): (1) The user clicks a deeplink from an untrusted/spoofed source; (2) The user accepts an installation prompt; (3) Local conditions permit child‑process execution or remote server addition (e.g., default policies, EDR/allow‑listing, user permissions). We did not observe a silent “zero‑click” path in default configurations.  

Cursor MCP install process  

Cursor hosts an online MCP Directory that makes MCP servers available for installation. 

Figure 6

Figure 6. Cursor MCP Directory (source:https://cursor.com/docs/context/mcp/directory). 

Installation process 

  1. User clicks a Cursor deeplink from a source (ideally trusted). 
  2. Browser prompts to open Cursor IDE. 
  3. Cursor displays an installation dialogue showing the MCP server name and parameters. 
  4. User clicks "Install" to approve. 
  5. Cursor adds the MCP configuration to ~/.cursor/mcp.json. 
  6. Cursor executes the configured command (subject to OS/user permissions and local security controls). 

During the installation process, the user is shown a preview of the configuration within an installation dialogue and is prompted that the MCP server will execute commands with the same privileges as the user. 

Figure 7

Figure 7. Installation dialogue for installing example MCP server. 

However, this warning is identical for all deeplinks, whether they are legitimate links from MCP directory or a malicious crafted deeplink. It is this mechanism that could be exploited to gain arbitrary local code execution or to socially engineer users into installing a malicious remote MCP server via deeplinks. Outcomes depend on environment, user privileges, and enterprise controls. 

Security considerations 

MCP servers create a new attack vector in AI development tools. Users are being encouraged to adopt AI, and many are writing and executing code for the first time without fully understanding security implications. The proliferation of AI coding assistants has normalized approval prompts, with even experienced developers becoming conditioned to approve in AI development environments. 

Cursor executes user-privileged commands when users accept the install prompt. The command field in the MCP configuration is executed directly by the IDE as designed. IDE’s that support MCP servers are commonly deployed on developers workstations which may have privileged access including SSH keys, API tokens, cloud credentials, source code, and access to production systems.  Controls such as EDR, allow‑listing, and OS policies may limit or block abuse depending on configuration. 

Deeplinks can use any name which can be used to masquerade as legitimate MCP servers (e.g., "Azure DevOps”) and there is no verification that the deeplink originates from the claimed vendor. Users should verify origin and review parameters prior to approval.   

CursorJack: proof of concept 

CursorJack is a proof-of-concept demonstrating that MCP deeplinks can be abused for local command execution or to install a malicious remote MCP server. The attack abuses the intended MCP installation flow combined with social engineering. 

For this proof of concept, where testing was conducted exclusively in Outlook, it is shown that a custom protocol handler like cursor:// can be used to phish users, even when Outlook does not render such links as clickable. Results may vary with other email services. Attackers may also deliver deeplinks via browsers, chats, or documents (such as PDFs). 

The phishing page redirects to the malicious deeplink, which encodes a malicious MCP configuration in base64. Once the user installs the MCP, the malicious installation command is executed.  

Command execution: Meterpreter Reverse Shell 

A phishing email directs the victim to a malicious landing page that triggers an MCP deeplink. The deeplink populates the mcp.json configuration with a malicious command that downloads and executes a batch script. This batch script functions as a stager and retrieves a Metasploit payload from attacker‑controlled infrastructure. The payload executes, establishing a full Meterpreter session that enables file system access, credential harvesting, and possible lateral movement. 

1. Phishing Link Delivered.  
 
The attacker sends a crafted HTTP link that email clients can render. 
 
Figure 8

Figure 8. Phishing email. 

2. When clicked, the phishing link redirects to a MCP install deeplink. This triggers the Cursor protocol handler, prompting the user to install the MCP within the Cursor IDE. 

Figure 9

Figure 9. Landing page with automatic JavaScript direct to Cursor deeplink. 

3. Malicious MCP config is accepted, triggering bat script download. 
 
Figure 10

Figure 10. Cursor install command. 

4. On install, Cursor executes the curl command to fetch run.bat from the attacker's server. 
 
Figure 11

Figure 11. CursorJack PoC hosting phishing page and attacker resources.

5. run.bat is a staging script that uses curl to download and execute the Metasploit payload (p.exe) to the temp folder.  

Figure 12

Figure 12. Contents of run.bat script which retrieves remote payload. 

6. Payload executes and launches Metasploit payload independent of Cursor process. 

Figure 13

Figure 13. Curl executing as a child process of Cursor. 

7. 

Figure 14

Figure 14. p.exe executing independently of Cursor. 

8. Reverse shell connects and Meterpreter establishes connection to attacker's listener. 

Figure 15

Figure 15. Successful Meterpreter session. 

Command vs URL exploitation 

Cursor's MCP can be configured via command or URL, and both paths are exploitable through deeplinks. While the POC used the command key to stage a payload, attackers could alternatively embed payloads directly in the deeplink or install a remote MCP via social engineering using the URL parameter. 

Command 

Command-based MCP grants immediate code execution with Cursor's privileges and persists across IDE restarts,  consistent with prior community reporting (CVE-2025-54136), with the install command executing each time Cursor is launched. Attackers can establish sessions, deploy software, or harvest credentials like SSH keys and API tokens including those stored in the mcp.json config itself. 

URL 

The URL key enables a different attack vector, socially engineering users into installing a malicious remote MCP server. While less powerful than local execution, this provides a foothold for MCP-based attacks like tool poisoning and cross-server manipulation, with lower visibility to security controls. 

Delivery methods and obfuscation tactics 

Mimic legitimate package installations  

Adversaries may disguise their payload delivery by using familiar developer binaries like npx or uvx to pull malicious code from seemingly legitimate locations. This approach blends in with standard package installation patterns, making the malicious activity appear routine and reducing opportunities for detection. 

Staging vs. embedded payloads  

Malicious MCP deeplinks could potentially deliver payloads via remote staging or direct embedding. Staged payloads leave fewer local artifacts but require C2 availability and may trigger detection through suspicious outbound connections. Embedded payloads could avoid external retrieval and can be swapped server-side without modifying the deeplink, but the payload is static once distributed and fully recoverable from the deeplink, potentially increasing likelihood of detection. Both approaches can be mitigated by strict allow‑listing and content inspection. 

Obfuscation techniques  

Command obfuscation can conceal malicious MCP configurations, exploiting the user-dependent approval flow. A resolved vulnerability (CVE-2025-54133), as reported by its discoverers, previously allowed hiding command arguments from the installation dialog. Attackers may use encoding techniques or excessively long command strings to push harmful arguments outside the preview window, reducing user scrutiny. 

Mitigations 

The MCP ecosystem requires fundamental security improvements embedded directly into the framework architecture, rather than relying on additional security tools or user vigilance as the primary defense. 

Regarding deeplink abuse, the installation process should address arbitrary command execution through the command parameter, such as through a more granular permissions model or containerization approach to isolate from the host OS. 

A trusted MCP ecosystem with signing and verified publishers for MCP servers, analogous to browser extension or app installation stores, would establish server authenticity. A robust code signing mechanism would ensure users can verify the source and integrity of servers before installation, creating a marketplace-like environment for trusted MCP integrations. 

Deeplinks from untrusted sources should be treated with the same caution as untrusted executables. Approval flows should incorporate granular security warnings and source verification to help users distinguish deeplinks from trusted and untrusted locations. Macros provide a strong security analogy: attackers historically manipulated users into enabling macros, resulting in arbitrary code execution. To mitigate this, internet‑sourced documents are tagged with Mark‑of‑the‑Web and subjected to stricter execution policies. 

Disclosure and relationship notes 

  • Proofpoint has no commercial, customer, partner, or vendor relationship with Cursor / Anysphere, Inc. 
  • Proofpoint does not compete in Cursor’s market segment (AI developer IDE/tools). Product names are used for identification only; nothing herein is an endorsement or warranty. 

We notified Cursor prior to publication; the report was closed as out‑of‑scope / Not Applicable under their policy. This post may be updated if Cursor issues guidance or product changes. 

To facilitate additional research and experimentation, we’ve made the CursorJack POC code available on GitHub