> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Claude Code Backdoor in Cursor Marketplace Drops SSH Keys - URL: https://debugly.dev/claude-code-backdoor-cursor-marketplace-ssh-persistence/ - Published: 2026-10-31T13:30:00.000Z - Updated: 2026-10-31T13:30:00.000Z - Description: Phorion found a backdoor in Claude Code 2.1.312 and 2.1.313 on Cursor Marketplace. It adds an SSH key and tries a reverse tunnel to 134.209.82.225. - Author: Rohit Bhadani - Tags: Security, AI A backdoored build of the official Claude Code extension for VS Code was distributed through the Cursor Marketplace and attempted to install a persistent SSH backdoor on macOS, Linux and Windows. The bundle versions are 2.1.312 and 2.1.313, both now removed by Cursor. The payload adds an attacker key to `~/.ssh/authorized_keys` and tries to open a reverse tunnel to 134.209.82.225 as user `tunnel`. It runs before the extension's normal activation, so no user click is needed. The details here come from Phorion's advisory published 31 October 2026, Cursor's security notice on the same day, and Hacker News discussion that made the report the top trending AI story on 31 October with 776 points and 485 comments. ## What was trojanized? | Property | Detail | | ----------------- | ---------------------------------------------------------------------------------------------------- | | Extension | Claude Code for VS Code, official bundle on Cursor Marketplace | | Affected versions | 2.1.312 and 2.1.313 for macOS and Windows, per Cursor's 31 Oct update. Phorion first flagged 2.1.313 | | Marketplace | Cursor Marketplace, not VS Code Marketplace or Open VSX | | Removal | Cursor removed both versions from its marketplace | | Implant type | Persistent SSH backdoor with host reconnaissance beacon | | Inbound key | Ed25519 public key with comment svc-telemetry appended to \~/.ssh/authorized\_keys | | Outbound tunnel | Reverse SSH to 134.209.82\[.\]225 port 22 as user tunnel with embedded private key svc-telemetry-tun | | Trigger | IIFE prepended to extension.js, runs on require before activate, no user interaction | The Cursor Marketplace serves extensions for the Cursor editor. Because extensions run with the permissions of the IDE and the user running it, a backdoored extension gets immediate access to local files, source code and developer tooling as soon as Node loads the file. According to Phorion, the compromised `extension.js` starts with an injected IIFE that pulls in Node modules and executes as soon as Node loads the file. ## How does the SSH persistence work? The payload prepares SSH access in two stages. First, it ensures `~/.ssh` exists and appends an attacker controlled Ed25519 public key to `~/.ssh/authorized_keys`, setting `0700` on the directory and `0600` on the file. Before appending, it checks whether the string `svc-telemetry` is already in the file rather than checking the key fingerprint. When hunting, check the fingerprint rather than relying solely on the comment. Second, it tries to ensure the SSH daemon will accept the key. On Linux it tries `systemctl`, on macOS it checks Remote Login and tries `sudo -n systemsetup -setremotelogin on`, and on Windows it tries PowerShell. None include a privilege escalation exploit. Next, the script opens a reverse tunnel to 134.209.82\[.\]225 as user `tunnel` with a separate private key. I reproduced the `authorized_keys` write in a disposable microVM at [Krova Cloud](https://krova.cloud/?ref=debugly.dev). ## Why did the macOS SSH check fail? On macOS the setup may fail before it reaches the `sudo` command. The script runs `systemsetup -getremotelogin` without elevation and tests the output against `/Off/i`. It only tries to enable Remote Login if the output contains `Off`. When run as a standard user, `systemsetup -getremotelogin` prints `You need administrator access to run this tool... exiting!` and exits 0\. The helper returns that string, so `/Off/i.test(rl)` is false and the script skips enabling Remote Login. On a Mac where SSH was off, that breaks inbound access, even though keys are still dropped. ## What should teams check today? Cursor has removed 2.1.312 and 2.1.313 from its marketplace, but the check is not the marketplace listing. It is what is already installed and what was left behind. - Search your fleet for Claude Code for VS Code `2.1.312` or `2.1.313` installed via Cursor Marketplace, per Phorion's guidance. Include macOS, Linux and Windows. - Inspect `~/.ssh/authorized_keys` for the `svc-telemetry` comment and, more reliably, for the attacker public key fingerprint. Check `~/.ssh` permissions and creation time. - Look for outbound connections to 134.209.82\[.\]225 on port 22 from developer hosts, and for `ssh` processes running as the user with the `tunnel` username. - Review whether `~/.ssh` or the tunnel key file was created around the time the extension was installed. According to Phorion, the implant also beacons host reconnaissance back to the operator, so the check should extend to any data the extension could read while running as the user, including source code and credentials stored in the home directory. The same isolation pattern I use for AI coding agents applies to IDE extensions. An extension that can read the home directory should not run on the same host as the signing keys. At [Krova Cloud](https://krova.cloud/?ref=debugly.dev) we run untrusted extensions and agent bridges in disposable Firecracker microVMs so the host does not share fate with the workload, as described in [agent sandbox checklist](https://debugly.dev/agent-sandbox-checklist/) and [sandboxing AI agent generated code](https://debugly.dev/sandboxing-ai-agent-generated-code/). ## What is the verdict and what remains uncertain? According to Phorion, the backdoor is in the official Claude Code bundle as distributed on Cursor Marketplace, not in a fork. According to Cursor's notice, the two affected versions for macOS and Windows have been removed. The payload is a significant threat that installs persistence and beacons host data, even where the macOS SSH enablement bug breaks the final inbound path. The verdict is to treat any host that loaded 2.1.312 or 2.1.313 from Cursor Marketplace as potentially compromised until the authorized\_keys file and outbound tunnel are ruled out. Removal of the extension from the marketplace does not remove what it already wrote to disk. The limitations are threefold. First, the Windows PowerShell path hardcodes `/bin/sh` in a helper, so it is unlikely to succeed on a standard Windows install. Second, the macOS enablement bug means many Macs that ran the extension will not have Remote Login enabled, which limits inbound access but not the persistence. Third, Phorion's writeup focuses on macOS and notes implementation bugs on the other platforms without a full detonation log for each, so the Linux and Windows details should be treated as described rather than independently reproduced. ### FAQ **Are we affected if we use VS Code Marketplace or Open VSX?** No, per Phorion and Cursor, the trojanized bundle was on Cursor Marketplace. The VS Code Marketplace and Open VSX are not listed as distribution points. **Does this affect the Claude Code CLI or the Anthropic API?** No. The advisory scopes the compromise to the VS Code extension bundle versions 2.1.312 and 2.1.313 as distributed on Cursor Marketplace. **What is the first indicator to hunt for?** The appended public key in `~/.ssh/authorized_keys` with comment `svc-telemetry`, verified by fingerprint, and the outbound reverse tunnel to 134.209.82\[.\]225\. Those two survive the macOS bug even where Remote Login was not enabled. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev) --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)