A Poisoned Extension Planted an SSH Backdoor: The Claude Code 2.1.312/2.1.313 Incident in Cursor's Marketplace

On the morning of October 29, if you updated the Claude Code extension inside Cursor, you may have installed a version that did not come from Anthropic. In a security notice published the same day, Cursor said that Anthropic.claude-code versions 2.1.312 and 2.1.313 for Windows and macOS, as they appeared in its own extension marketplace, were "maliciously modified versions" not developed by Anthropic. They install a persistent SSH backdoor on your machine: adding an attacker's key, attempting to open a reverse tunnel, and using scheduled tasks to keep the tunnel alive. The exposure window lasted about 11 hours, from around 2:27 a.m. to 1:35 p.m. Pacific Time. Cursor said on X that at most 5,000 users were affected and that it would contact them directly.

The most important conclusion comes first: if you installed or updated one of these versions from Cursor's marketplace during that window, do not stop at uninstalling the extension. Cursor's notice is blunt about this — uninstalling may not be enough, because the payload drops standalone persistence scripts that keep running. First check your SSH authorized-keys file for a key labeled svc-telemetry. If it is there, follow the notice's cleanup scripts and isolation steps. If it is not, you can breathe easier. For users who installed Claude Code from Microsoft's official marketplace, Open VSX, or npm, Cursor's position is that there is "no evidence that other versions of the extension or the official distribution are affected," and Socket's registry checks point the same way: version 2.1.313 left no publication record in either of those places.

What the tampered builds actually did

According to Cursor's notice, the malicious build inserted a loader ahead of the extension's normal code, and once activated it did four things. First, it collected and reported host and user information: hostname, username, operating system, architecture, home directory path, environment variable names, working directories, the configured Git email address, and the public IP address. One wording detail is worth pausing on: the notice says "environment variable names," not values. Names alone do not hand over your secrets, but they tell an attacker whether the machine is worth coming back to — and Cursor warns that the limited collection does not rule out later credential access through the backdoor.

Second, it tried to append an attacker-controlled SSH public key to your authorized_keys file, commented svc-telemetry, with a fingerprint beginning SHA256:0Z6R. Third, it tried to enable the local SSH service and open a reverse SSH tunnel to 134.209.82.225. Fourth, it made the tunnel persistent: on macOS, a LaunchAgent disguised as a system component (labeled com.apple.sysmond); on Windows, a scheduled task called SysMon that attempts to run as SYSTEM, with a Startup-script fallback. Background scripts retried the tunnel roughly every 60 seconds.

There is a crucial qualification that often gets dropped in retellings: enabling the local SSH service requires administrator privileges, which the malicious extension does not have on most macOS and Windows hosts. Cursor's own words are that, outside highly unusual circumstances such as Cursor being started with administrator privileges, this step would fail, and the attacker could not have logged in through the tunnel on those hosts. But that is far from "nothing happened": the key was written, the persistence was installed, and the host details were sent. The notice explicitly requires the full remediation flow regardless of whether the tunnel connected.

The good news is that the other end of the attack chain is dead. Cursor says it worked with the cloud provider hosting the attacker's server to take it offline, so the reverse shell and the host-detail POST no longer function. The "in progress" phase of this incident is over — but what was left behind is not. Keys, persistence scripts, and scheduled tasks do not remove themselves just because the server went dark.

If you updated during the window, do these three things

Step one: check for the key, no tooling required. On macOS, run the command from Cursor's notice in a terminal: grep -qs svc-telemetry ~/.ssh/authorized_keys. If it prints "svc-telemetry key found," the machine is affected; "No key found" means, in the notice's terms, that it is not. On Windows, use PowerShell to check both the user's authorized_keys file and C:\ProgramData\ssh\administrators_authorized_keys. Checking only one file is not enough, because the administrator authorized key may live in the second location.

Step two: if you find the key, isolate first, then clean up. The notice's order is worth copying exactly: isolate hosts showing evidence of payload execution or backdoor installation; remove the unauthorized key, the persistence mechanisms, and the running tunnel processes using the official remediation scripts; the macOS script, remediate-macos.sh, must run as the affected user, not as root, while the Windows script, remediate-windows.ps1, must run from a PowerShell session opened with administrator rights. The scripts exit with a non-zero status if anything remains — treat that as your acceptance test, not a formality.

Step three: rotate credentials and sessions reachable from the affected host, from a trusted system. The notice deliberately notes that the limited environment-variable collection does not rule out later credential access over the backdoor. In other words, checking for the key only confirms whether you were hit, not the boundary of the damage. Individual developers should at minimum rotate Git hosting and cloud tokens and re-authenticate to critical services; teams should treat the machine as a formal security incident and assess whether it should be rebuilt. Cursor's wording is "assess whether the host should be rebuilt." My judgment: for any machine that held production secrets, rebuild it outright rather than debating it.

One easily missed step: confirm you are now on a clean version. Anthropic has published 2.1.314, and the public release record jumps straight from 2.1.312 to 2.1.314 — there is no 2.1.313 entry. Before upgrading to 2.1.314, confirm the old residue is gone using the method above. Otherwise the new version goes on top while the old persistence script is still retrying its tunnel every minute in the background.

Why the first reports pointed at the wrong place

This incident has a second story worth telling separately: its attribution trail. The earliest security analysis pointed at Open VSX — the open extension registry run by the Eclipse Foundation, which editors built on open-source VS Code, including Cursor and Windsurf, rely on instead of Microsoft's store. Socket's subsequent investigation produced the opposite evidence: across 3,392 registry change events from October 27 to 30, Open VSX contained ACTIVE records for all eight platform builds of both 2.1.312 and 2.1.314, but no publication or removal event for 2.1.313 at all. The npm record for @anthropic-ai/claude-code likewise skips 2.1.313 (2.1.312 was published October 27 at 18:36 UTC; 2.1.314 on October 30 at 00:12 UTC). Open VSX's change history is append-only by design, so even a briefly listed and quickly removed version should leave a trace — in the same window, 42 versions across 21 other extensions were removed and all retained their records, including one that lived for about 90 seconds.

The more accurate account, then, is that the malicious build was distributed through Cursor's own marketplace, not through Open VSX or npm's official distribution. Cursor's notice says exactly that: the problem was in the "Cursor VS Code Extension Marketplace," with no evidence that other versions or the official distribution were affected. The original analysis has since been substantially revised and no longer names Open VSX as the affected channel. The correction itself is the lesson: in the first hours of a security incident, the channel name in secondhand reports is the detail most likely to be wrong — and for ordinary users, the channel name is precisely what determines "do I need to check?" Get it wrong, and the people who should check feel safe while others waste effort checking the wrong place.

One question remains unanswered: how did a tampered package carrying Anthropic's official extension ID (anthropic.claude-code) get published to Cursor's marketplace? Cursor's notice describes the response — immediate removal, blocking further distribution, a precautionary shutdown of the entire marketplace, an audit confirming no other extensions were tampered with, key rotation, and a rebuilt marketplace brought back online — but it does not explain the publication path. An Anthropic technical staff member said on social media that it "wasn't a compromise of Anthropic's systems or employee laptops." Until an official postmortem appears, any theory about an insider or a marketplace review gap is speculation, and this article does not adopt one.

Why Cursor's marketplace, and not Microsoft's

To understand the channel dispute, you need the triangle behind VS Code extension markets. Microsoft's Visual Studio Marketplace, by its terms of use, serves Microsoft's own products only; editors built on the open-source VS Code codebase — Cursor and Windsurf included — cannot use it. That leaves two routes: the Eclipse Foundation's open registry, Open VSX, or a self-built marketplace like Cursor's. In daily use the difference is invisible: you click install and the extension arrives, and which registry served it barely registers. When something goes wrong, the difference becomes immediate: you first have to figure out which marketplace you installed from before you can tell whether you are in scope.

That is where the original misattribution did its most damage. Many Cursor users also run VS Code, sometimes on different machines, and a headline saying "Open VSX has a problem" could easily send them to check the VS Code side, find nothing, and relax — while the Cursor marketplace they should have checked went unexamined. Socket's verification mattered not just because it corrected a name, but because it re-anchored the self-check to the right scope: Cursor's marketplace, versions 2.1.312 and 2.1.313, the window from 2:27 a.m. to 1:35 p.m. Pacific on October 29. All three conditions must hold before the cleanup flow applies; miss one, and you are out of scope.

It also raises a deeper question: who owns review responsibility for a self-built marketplace? Microsoft's store has Microsoft's review process, Open VSX has foundation governance, and Cursor's marketplace is operated by Cursor itself. When a package wearing Anthropic's official ID appears in Cursor's marketplace, users have no simple client-side way to tell it apart — the publisher identifier shown in the extension details is exactly the one being impersonated. The checks available on the client are thin: whether the version number exists in the official release record is one, but users cannot realistically flip to GitHub's release page to compare on every update. What can actually hold the line is signature and publisher-identity verification on the marketplace side: only submissions holding Anthropic's publishing credentials should be able to ship under anthropic.claude-code. Cursor's notice says it "rotated keys and rebuilt the marketplace," which hints the problem may have involved marketplace-side credentials or process, but the notice does not say so, and this article will not fill in that inference. What users can do is wait for the official postmortem rather than guess.

For vibe coders, the triangle has a practical implication: you are probably a user of several markets at once. One version of Claude Code in VS Code, another in Cursor, a CLI copy from npm on the same machine — three distribution channels, three update rhythms. A simple rule helps: install high-privilege coding-assistant extensions from one channel only and follow one update source; if you must use several editors, at least write down which marketplace each editor's version came from. When an incident lands, that list shrinks the self-check from "every machine" to "a few machines, one marketplace."

A 24-hour response checklist for teams

If you run security or engineering productivity for a team, you can use this checklist directly as an incident response template. Its clock starts not at "saw the news" but at "confirmed someone on the team updated during the window." Hours 0–1: send an internal notice stating the three conditions — Cursor's marketplace, 2.1.312 or 2.1.313, October 29, 2:27 a.m. to 1:35 p.m. Pacific — and ask everyone to check authorized_keys before uninstalling anything. Uninstalling deletes evidence and does not remove the persistence scripts; getting the order wrong creates extra work.

Hours 1–4: collect self-check results into three buckets. Bucket one: machines where the svc-telemetry key was found — isolate immediately, run the official cleanup scripts, assess a rebuild. Bucket two: machines updated during the window without a key hit — still run the cleanup scripts and check the persistence locations (the com.apple.sysmond LaunchAgent on macOS, the SysMon scheduled task and Startup script on Windows), because the notice's persistence list is longer than one key. Bucket three: machines not updated during the window — record the version, no action needed. The point of the buckets is that "no key found" must not automatically mean "fine" — the notice's indicator list treats files, process command lines, and network beacons as independent evidence points.

Hours 4–24: three closing tasks. First, rotation: every credential and session reachable from a hit machine gets rotated from a trusted machine, including Git hosting tokens, cloud keys, and internal system sessions. Second, a baseline: pin the team's Claude Code extension version to 2.1.314 and write the three version numbers — 2.1.312, 2.1.313, 2.1.314 — into the internal knowledge base, noting that 2.1.313 does not exist in the official release record, so any future build claiming that version should be treated as suspicious on sight. Third, a marketplace-trust review: assess whether high-privilege extensions need centralized management — installs restricted to fixed channels, personal major-version updates disallowed, or at minimum a queryable record of who installed which version. The most expensive part of this incident was not the cleanup; it was the uncertainty of "we don't know who installed it."

Individual developers can shrink the checklist to one sentence: check the key, run the script, rotate credentials, pin the version. Once those four are done, this incident is over for you. Three things not to do: do not declare it handled after only uninstalling the extension; do not install a supposedly clean build downloaded from an unofficial channel over the top; do not keep using a hit machine to push code or touch production before it is isolated.

How this differs from the usual npm supply-chain attack

For years, JavaScript supply-chain incidents have mostly lived at the package-registry layer: a maintainer account gets stolen, or a new package squats on a famous name, and developers pull malicious code into a project with npm install. The defenses are correspondingly mature: lock versions, audit dependencies, run SCA scans. Cursor's incident has a different attack surface: it is not in your project dependencies but in your editor. You were not hit while installing some library; you were hit while updating an official tool you use every day.

The privilege level differs too. Malicious code in a project dependency usually operates within the project directory and the build process, with the permissions of whoever runs the build. An editor extension is born with permission to read your code, run your terminal, and change your configuration — and a coding-assistant extension like Claude Code sits at the top of that privilege ladder. The malicious build aimed precisely there: the SSH authorized-keys file, persistence tasks, a reverse tunnel. These are not things an ordinary dependency package reaches for. In other words, the attacker did not pick the easiest door in; they picked the highest ground once inside.

One more difference is worth noting: this payload has a distinctly half-finished character. The tunnel step failed on most machines for lack of administrator privileges, while the persistence was quite systematic — a disguised LaunchAgent, a SYSTEM scheduled task, a Startup-script fallback, 60-second retries. That "partially successful" shape is exactly why "was anyone remotely logged into?" is the wrong test for damage. Host information already left the machine, the key was already written, and the foothold was already in place. Taking the server offline cut the remote control, not the foothold itself. Understanding that is understanding why Cursor insists every window-period user run the full cleanup, rather than only those confirmed to have been logged into.

Source note: the core facts in this article come from Cursor's official security notice (exposure window, payload behavior, indicators, and cleanup steps follow the notice's text). The "at most 5,000 users" figure and the marketplace-rebuild details come from Cursor's statements on X as relayed by Socket, The Hacker News, and other secondary coverage; the finding that Open VSX and npm hold no 2.1.313 record comes from Socket's public analysis. Cursor has not yet explained how the tampered package entered its marketplace, and this article does not speculate on that point.