Update: Mauro Soria pointed out that this attack vector can be easily adapted for phishing scenarios:
Share a GitHub repo
Give some instructions to access the attacker server with Cursor or VS Code.
Basically, if you click on something like vscode://vscode-remote/ssh-remote+user@hostname/home/user/project to open VS Code, you might get popped!
In a recent red team engagement, the client's attack surface was so well-defended that after months of effort, the only system we managed to compromise was a lone server, which was apparently isolated from the rest of the network. Or so we thought.
One developer had been using that server for remote development with Cursor. This setup is becoming increasingly popular: developers run AI agents remotely to protect their local machines.
But when we dug deeper into how Cursor works, we discovered something unsettling. By pivoting through the remote server, we could actually compromise the developer's local machine.
This wasn't a Cursor-specific flaw. The root cause lies in the Remote-SSH extension that Cursor inherits directly from VS Code. Which means the attack path we uncovered could extend across the entire VS Code remote development ecosystem, putting any developer who connects to an untrusted server at risk.
On the Remote-SSH extension page, Microsoft states:
Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
Despite clear warnings, a dangerous misconception persists among developers that "remote development" is fully isolated on the server. This belief is increasingly common as developers use remote environments as "sandboxes" to safely run AI agents without risking their local machines.
Given this powerful use case, the assumption of total isolation is understandable. However, Microsoft has suggested that no changes will be made to enhance the extension's safety to meet this expectation. This raises a critical question: how hard is it for your machine to be compromised if you connect to an untrusted server?
The answer: it's easy. Once the server is hacked, you are hacked as well. Thomas Ptacek outlined several attack paths, and our research uncovered a method to compromise the client without delving into low-level details. Our attack works in the default settings of Cursor or VS Code.
When you connect to a remote development server, a malicious extension on the server can execute the workbench.action.terminal.newLocal command to open a terminal on your local machine. This is a terminal on your local machine, not the server. Once the terminal is open, the extension can execute the workbench.action.terminal.sendSequence command to send text to the terminal and get it executed with a new line character (as if pressing Enter). We can also leverage another feature to establish a seamless Command & Control channel between the server and the local machine, but that is beyond the scope of this post.
Our goal in publishing this post is to raise awareness of the risks of remote development and to call for improvements that address the root causes of this issue. Monitoring the ~/.cursor-server directory for changes can serve as a workaround, but it offers limited protection if the server is fully compromised. Securing the Remote-SSH extension is a better approach. For example, requiring user approval when a remote extension attempts to open a new local terminal or send keys to an active local terminal would help block the described attack. As there might be other attack vectors, fixing this issue entirely will take significant effort. A good direction is to move toward secure-by-default designs that don’t rely on users making trust decisions.
Contributors: Tuyen Le, An Nguyen, Khanh Pham