On 29 October 2026, a manipulated version of the official Claude Code extension was available in the Cursor Extension Marketplace for around eleven hours (versions 2.1.312 and 2.1.313). The manipulated version was designed to set up a persistent SSH backdoor on the machine. Cursor detected the incident, took the marketplace offline completely for a while and reopened it after an audit and a key rotation.
What the malicious code did
As soon as the extension was loaded at editor start, the malicious code attempted the following:
- SSH backdoor: the attacker’s public key was appended to
~/.ssh/authorized_keyswith the harmless-looking labelsvc-telemetry, and a reverse SSH tunnel to the attacker’s server was set up. - Data exfiltration: host name, user name, OS, home directory, Git email address, public IP and the names (not the values) of up to 40 environment variables containing KEY/TOKEN/SECRET/PASS/AWS/GCP. This told the attacker which cloud credentials were stored where.
- Beacon: the host data was reported to the attacker over unencrypted HTTP.
- Persistence: the backdoor was secured by a LaunchAgent (macOS) or a scheduled task plus a startup script (Windows), which were meant to restore it if it was removed.
A stroke of luck: starting the local SSH service requires admin rights, which the extension did not have on almost all machines. The malicious code also contained a bug, so this step failed. Placing the SSH key and exfiltrating the data worked nonetheless.
Who is affected
- At most 5,000 developers installed the malicious version; Cursor contacted them directly.
- The access most likely affected only the Cursor marketplace. The Claude Code repository, npm and the Microsoft VS Code Marketplace are not affected; Anthropic stresses that its own systems are clean.
- Had the Claude Code repository itself been compromised, considerably more developers – and indirectly many more end customers – could have been affected.
How to fix it
The remediation is described here: https://cursor.com/blog/claude-code-extension-security-notice
Countering such attacks with VM or Docker sandboxes
Short answer: it works.
The core problem with this kind of attack: an AI coding assistant (or the IDE and its coding agent extension) often runs with the user’s full rights on a machine that, in many cases, also holds credentials (e.g. AWS_ACCESS_KEYS). The agent’s own sandboxing mechanisms, usually based on the operating system, can generally be overcome with little effort (or developers click away access confirmations out of habit). Sandboxing with virtual machines or Docker is the better option.
The supply chain is not the only attack vector: prompt injection, malicious instructions from files or repositories the agent reads (gitspawn, https://www.manifold.security/blog/ai-coding-agents-git-hijack), an agent that runs the “wrong” commands – all of these hit the same machine with the same secrets.
The one measure that helps is the sandbox:
- Run the agent and the IDE in a sandbox (Docker/VM): in Docker (e.g. https://code.claude.com/docs/en/devcontainer) or in a VM (e.g. via https://microsandbox.dev). Using https://guix.gnu.org also opens up many options (not only for AI sandboxing: https://200ok.ch/posts/2025-05-23_sandboxing_ai_tools:_how_guix_containers_keep_your_host_safe_while_empowering_llms.html, https://guix.gnu.org/cookbook/en/html_node/Guix-Containers.html). Solutions such as Microsandbox start the VM quickly (< 100 ms, plus the coding agent or IDE).
- No credentials at all inside the sandbox. If the agent has no API keys, Git tokens or database passwords in its environment, an attacker has nothing to exfiltrate.
- Provide the required credentials outside the sandbox, e.g. through proxies such as Llama Swap or LiteLLM: the agent talks to a local proxy that keeps the actual secrets for accessing the LLM outside the sandbox and forwards only the calls that are needed.
- Restrict access: some solutions can also limit network access to specific domains; whitelisting is generally the better approach. Keep the .ssh directory out of the VM as well and prevent access to it.
- Cloud: VMs in the cloud are another option, with many different approaches possible.
Proper sandboxing significantly reduces the potential blast radius of these attack vectors, while the effort stays manageable. In an agentic workflow, sandboxing is not a nice-to-have but an important line of defence. If you use a command-line coding agent such as OpenCode (or the command-line version of Claude Code) and want to keep the VM lightweight, you can also run the IDE outside the VM, share the project directory and need no secrets in the VM at all. Such a setup does not, of course, protect against other compromised extensions.
A sandbox cannot prevent every attack. It can, however, significantly increase the effort an attacker needs for a successful attack.
Conclusion
The Claude Code / Cursor hack shows that the supply chain of AI development tools is an attractive target, too. At the same time, there are concepts that can considerably reduce the potential impact of an attack and take only little effort to set up.
For questions or support in securing your development process, contact Felix Eckhardt or Mark Holst.
About the author
Felix Eckhardt
CyberSecurity Lead
He has been with Silpion since 2011, with experience as a back-end and front-end developer, DevOps engineer, architect, Scrum Master and cybersecurity lead, as well as a consultant, trainer and speaker. He is also actively involved in our in-house training programmes.