Claude Code Extension Backdoor: Are You Affected? (Oct 2026)

By devopscompass
Fact card on the Claude Code extension backdoor: about 11 hours online, versions 2.1.312 and 2.1.313, key named svc-telemetry

In short: On 29 October 2026 (about 2:27 am to 1:35 pm PT) a tampered copy of Anthropic's Claude Code extension, versions 2.1.312 and 2.1.313, was served from the Cursor VS Code Extension Marketplace for Windows and macOS. It tried to plant an SSH key labelled svc-telemetry, open a reverse SSH tunnel, persist, and report host details to the attacker. Cursor says the code was not developed by Anthropic; an Anthropic engineer says the official VS Code marketplace and Open VSX were not affected. Check: grep -s svc-telemetry ~/.ssh/authorized_keys. If it matches, uninstalling is not enough. How this article was made: we read Cursor's security notice, Phorion's technical advisory and the Hacker News threads. We did not install or run the extension.

The story broke on Hacker News on 30 October (857 points). The practical questions are: am I affected, how do I check, and do I need to rotate secrets? We keep official facts, what users report and our take apart, and we mark where sources disagree.

Official facts

Checked on 31 October 2026 against Cursor's security notice (published 29 October, updated 30 October 11:30 am PT) and Phorion's advisory (published 30 October, updated 31 October).

What Malicious versions of the Anthropic.claude-code extension on the Cursor marketplace
Versions 2.1.312 and 2.1.313 (Cursor's update of 30 Oct; Phorion first named only 2.1.313)
Platforms (Cursor) Windows and macOS
Window about 2:27 am to 1:35 pm PT, 29 October 2026 (about 11 hours)
Trigger Code injected at the start of extension.js runs when the file loads, before the extension's normal activate (Phorion)
Cursor's response Removed the versions, shut the marketplace down briefly, audited other extensions, rotated keys, rebuilt it, and had the attacker's server taken offline
Attacker server Cursor says it "no longer functions"

What the payload does

Per Cursor and Phorion:

Four-step diagram of the attack: install from the Cursor marketplace, code runs on load, SSH tunnel persists, beacon reports host info
Attack chain from the Cursor notice and Phorion's analysis. Diagram: DevOpsCompass.
  1. Adds an SSH key with the comment svc-telemetry to ~/.ssh/authorized_keys.
  2. Tries to enable the local SSH service (on macOS with sudo -n systemsetup, on Linux with systemctl, on Windows by installing OpenSSH Server). This needs admin rights. Cursor says that on most macOS and Windows hosts this step fails, so the attacker could not have logged in through the tunnel. Phorion found a bug in the macOS check that skips the enable step, and adds that this is not something to rely on, because SSH may already be on.
  3. Opens a reverse SSH tunnel to 134.209.82.225 and retries about every 60 seconds.
  4. Persists: a LaunchAgent named com.apple.sysmond on macOS, a SysMon scheduled task or Startup script on Windows, an @reboot cron entry on Linux, plus hidden files ~/.config/.smt and ~/.config/.smtk.
  5. Beacons host information over plain HTTP: hostname, user, OS, home directory, Git email, public IP and the names (not values) of up to 40 environment variables matching KEY|TOKEN|SECRET|PASS|AWS|GCP.

Which versions and platforms are affected?

  • Versions: 2.1.312 and 2.1.313, as served by the Cursor marketplace. Cursor: "We have no evidence that other versions of the extension or the official distribution are affected."
  • Platforms: Cursor lists Windows and macOS builds. Phorion's analysis says the implant also contains Linux logic, and Cursor's indicator list includes Linux paths, so Linux users who ran Cursor with the extension should run the checks below as well. This is a gap between the two sources that we cannot settle.
  • Dates: Cursor dates the incident to 29 October; Phorion's post is dated 30 October because it was published a day later.

Am I affected if I use VS Code, not Cursor?

According to Anthropic's David Dworken (HN user ddworken), the issue "only impacted the extension as it was hosted on the Cursor marketplace. It did not impact the official VS Code extension marketplace or OpenVSX. Users of Claude Code on VS Code are not impacted." He also said the marketplace is a third-party one that Anthropic is not involved in "owning, maintaining, deploying, or reviewing" (comment 1, comment 2). Anthropic had not posted anything on its newsroom when we checked on 31 October.

Cursor's help page says it routes extension searches and downloads through its own marketplace proxy rather than passing straight through to Open VSX (quoted in a Hacker News comment). That is why people using other VS Code forks that talk to Open VSX directly are, on current information, not in scope. If you use Cursor, check, even if you did not use Claude Code "inside" Cursor, because auto-update can install a new version in the background.

Who was compromised: Anthropic or Cursor?

Not settled. Cursor says the versions "were not developed by Anthropic" and that it audited its own marketplace and rotated keys. Anthropic's engineer says the problem was specific to Cursor's hosting. Neither company has published how the tampered file got into the marketplace or whose credentials were used. Hacker News readers pointed out the same gap (see below). Until a post-mortem appears, treat "supply-chain compromise of a marketplace" as established and "root cause" as unknown.

How do I check my machine (macOS, Linux, Windows)?

Three-step response diagram: check authorized_keys for svc-telemetry, remove persistence and the key, rotate secrets
Response steps summarised from Cursor's notice. Diagram: DevOpsCompass.

macOS and Linux, command from Cursor's notice (macOS) and the same idea on Linux:

grep -s svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found"

A more robust test is to compare key fingerprints, because Phorion notes the malware tests for the comment text, not for the key itself. The planted key's fingerprint is SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk:

ssh-keygen -lf ~/.ssh/authorized_keys | grep '0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk'
ls -a ~/.config/.smt ~/.config/.smtk
crontab -l | grep smt                       # Linux
ls ~/Library/LaunchAgents/com.apple.sysmond.plist   # macOS

Windows (PowerShell), from Cursor's notice:

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }
Terminal output of the svc-telemetry checks on a clean Linux server: no key found, fingerprint count zero, no hidden files
The check commands run on our clean Linux server (not a Cursor machine). Screenshot: DevOpsCompass.

What we did run: the grep, fingerprint and file checks above on our own Linux server, which has no Cursor and no extension. They returned "No key found" and no files. That only proves the commands run, not that your machine is clean. Cursor also offers remediate-macos.sh and remediate-windows.ps1 on its notice page; we did not run them.

You can also look for network traces: outbound SSH or HTTP port 8099 to 134.209.82.225, and ssh -N -R '*:0:localhost:22' or autossh -M 0 processes. See our guide to what an SSH warning actually means if you want a refresher on reading SSH client output.

Is uninstalling the extension enough?

No. Both Cursor and Phorion say the payload drops standalone persistence scripts that keep running after the extension is removed. The steps they describe:

  1. Kill the retry loop and any ssh or autossh process connected to 134.209.82.225.
  2. Remove persistence: the LaunchAgent, the @reboot cron line, the SysMon task and sysmon.cmd, and ~/.config/.smt / .smtk.
  3. Delete the svc-telemetry line from authorized_keys and any /tmp/.stk_* files, and confirm that SSH (Remote Login) was not switched on unexpectedly.
  4. Or run Cursor's remediation script for your OS, which exits non-zero if anything remains.
  5. Decide whether to rebuild the host if you see evidence that someone logged in. Phorion notes that successful logins through the tunnel would appear in SSH logs as coming from localhost with the svc-telemetry key.

Phorion also warns that the Linux persistence has a bug in its crontab check that can wipe existing user cron jobs on repeat runs, so back up crontab -l first if you can.

Do I need to rotate credentials?

Cursor says to rotate credentials and sessions reachable from affected hosts, from a trusted system, because "the limited env-var collection does not rule out later credential access over the backdoor." Practically: if the key was found, rotate what a developer machine holds, such as cloud keys, Git and registry tokens, SSH keys and .env secrets. If the key was not found, Cursor's own advice is that the machine is not impacted. The beacon sent only variable names, not values, per Phorion and Cursor.

How to reduce the risk from editor extensions

These are suggestions from our reading and from attributed community comments, not vendor guidance, and we did not test them.

  • Delay auto-updates. A Hacker News user said VS Code recently added an extensions.autoUpdateDelay setting (user comment; we did not verify the setting). Another suggested updating manually only after a version is 3+ days old (user comment). Here the bad version lived about 11 hours.
  • Know that extensions have no sandbox. Users noted that locally installed VS Code extensions run with your user's permissions and that a request for permission limits has been open in the VS Code repository since 2018 (issue 52116, linked in HN).
  • Isolate the agent. Commenters described running coding agents in a container or microVM that mounts only the current project (example), or running the editor server in a VM. Anything you mount can still be read.
  • Watch ~/.ssh. Any editor process writing to authorized_keys is suspicious. This is an inexpensive monitoring rule.

For agent-tool risks in a related setup, see our Terraform MCP server safe-use guide.

What users report

From the Hacker News threads of 30 October 2026 (main thread, 857 points). They are opinions and unverified by us. Reddit blocks our fetch tools, so we did not read it.

  • Scale. mindracer noted that the extension has "over 27 million installs" (their figure; the Cursor-marketplace number is not stated).
  • Confusion over scope. ale42 asked whether this hits only Cursor users or all VS Code users; xx_ns first said it was Open VSX, then edited to say the sources only mention Cursor.
  • Transparency. Rapzid wrote that nobody is taking responsibility for what was compromised, and that Cursor "conspicuously left these details out".
  • Review claims. no-name-here quoted Cursor's help page, which says extensions go through automated malware analysis before being served, and noted that the bad extension was live for about 11 hours.
  • The mirror theory. Lazare said Cursor runs its own mirror of Open VSX and that Cursor claims the tampered files were only on that mirror.
  • Permissions. ashishb argued that extensions should not have full access to the home directory.

Our take

  • If you use Cursor with the Claude Code extension on macOS or Windows: run the check today. It takes one minute, and the window was only 11 hours on 29 October.
  • If you use the official VS Code marketplace or the Claude Code CLI: on current information you were not in scope, per Anthropic. Not a reason to stop using Claude Code.
  • The lesson is about trust chains. The file was "official" in name but arrived through a third-party marketplace. The first thing to ask of any editor extension is who serves it, and whether a stolen publishing key could push an update to millions of installs.
  • What we want to see: a post-mortem from Cursor and Anthropic with the root cause, how long the key was exposed and whether any other publisher was touched.

What we did not test

  • We did not download, install or run the extension, and we did not run Cursor's remediation scripts.
  • Everything about the payload comes from Cursor and Phorion; we did not reverse-engineer it.
  • The check commands were run only on a clean Linux server, to confirm syntax.
  • Hacker News comments are opinions; Anthropic's statement was read on Hacker News, not on an Anthropic page.
  • We could not read the Doublepulsar article (blocked for our tools) or Reddit.

FAQ

Is the Claude Code extension safe to use?

According to Anthropic's engineer, the official VS Code marketplace and Open VSX were not affected, and only versions 2.1.312 and 2.1.313 served by the Cursor marketplace were malicious. Cursor says it has no evidence that other versions or the official distribution were affected.

Is Cursor safe to use?

Cursor says it audited its marketplace, confirmed no other extensions were tampered with, rotated keys and rebuilt it. The incident shows the marketplace can be a weak point. Decide based on your own risk tolerance until a root-cause report appears.

What did the malicious extension steal?

By Cursor's and Phorion's descriptions: host details (hostname, user, OS, home path, Git email, public IP) and the names, not values, of environment variables that look like keys or tokens. It also tried to give the attacker SSH access, which could expose more if it worked.

What is the svc-telemetry SSH key?

It is the comment on the attacker's public key that the extension adds to authorized_keys. The key's fingerprint is SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.

How long was the malicious version online?

About 11 hours, from roughly 2:27 am to 1:35 pm PT on 29 October 2026, per Cursor's notice. Cursor removed the versions and rebuilt its marketplace afterwards.

Does the attacker still have access?

Cursor says the attacker server was taken offline with the hosting provider's help, so the tunnel and beacon no longer work. The planted key and persistence stay on infected hosts until you remove them.

Do extensions in VS Code run in a sandbox?

No. Extensions run with the permissions of your user account, as Phorion notes, so a malicious one can read your files and write to ~/.ssh.

Sources

Update log

  • 31 October 2026: first version (Cursor notice as updated 30 Oct, Phorion advisory as updated 31 Oct, Hacker News reactions, Anthropic statement via HN).

Last verified: October 2026 (31 October 2026). Affected versions, scope and the root cause may change; we will update this page and the log above.

Header image: Image: DevOpsCompass.

Comments