Cursor’s Marketplace Served a Tampered Claude Code Extension With an SSH Backdoor for 11 Hours, and Its Notice Now Names Two Versions Instead of One

Cursor says a maliciously modified copy of Anthropic’s Claude Code extension was available in its VS Code extension marketplace between about 2:27 a.m. and 1:35 p.m. Pacific time on Thursday, October 29, which is 09:27 to 20:35 UTC, or 11 hours and 8 minutes. The added code runs as soon as the extension loads. It adds an attacker’s SSH key, labeled svc-telemetry, to the user’s authorized_keys file, tries to turn SSH on, opens a reverse SSH tunnel to a server the attacker controlled, installs persistence and sends a host profile to that server. Anthropic says its own systems were not compromised and that a malicious actor used access to Cursor’s marketplace to publish the copy. Neither company has said how that access was obtained.

The notice has changed since the first reports, and the changes matter to anyone hunting for this. The earliest archived copy of Cursor’s notice that we could read, from 08:43 UTC on October 30 (a later one, from 12:48 UTC, is identical), names one version, 2.1.313, and says “At most 5,000 users were affected, and we will reach out directly.” The current page, updated at 11:30 a.m. Pacific (18:30 UTC), names 2.1.312 and 2.1.313 for Windows and macOS, carries no user count and lists different file hashes. Version 2.1.312 is a genuine release that Anthropic published on October 27, so a version check cannot separate a tampered copy from a real one; Cursor’s own cleanup scripts say “The tampered bundle keeps the real version number, so match on content.” Version 2.1.313 appears in none of Anthropic’s official channels today. The reassurance that the SSH step “would fail” is also narrower than it reads. Below we set out the timeline, what the notice changed, the version evidence, which steps need administrator rights, how to check a machine, and what no source has said.

What happened, in order

Times are UTC unless marked. Release times come from the npm registry, GitHub’s API, the Open VSX API and the Visual Studio Marketplace’s public query API. The notice’s times come from Cursor and the Wayback Machine. Weekdays, offsets and durations are our arithmetic (Pacific time was UTC minus 7 on these dates).

What Cursor’s notice changed

BleepingComputer and The Register reported what the notice said when they published, so the differences below belong to the notice, not to them. We compared the archived copies captured at 08:43 and 12:48 UTC (identical to each other) with the page as it stands now (we fetched it again at 19:20 UTC and it matched our first read). The notice is dated October 29 and the earliest capture is from the morning of October 30, so we have not seen the text as first published.

Two effects follow. First, the darwin-arm64 hash in the archived list (432ccdee…) appears nowhere on the current page, and the win32-x64 hash the archived list gave for 2.1.313 (3de17229…) now sits under 2.1.312. Anyone who copied indicators from an archived version should pull the current list from Cursor’s notice. Second, the “up to 5,000” in both news stories matches the sentence in the archived versions. The current notice has no count, and neither Phorion’s write-up nor OpenSourceMalware’s gives one (we searched all three pages for “5,000”). Nothing public says how the figure was derived or whether it holds for 2.1.312.

Why a version number cannot tell you

Anthropic’s VS Code documentation says “The extension’s version number is the Claude Code version it bundles,” and tells readers to “Click the link for your IDE to install directly,” with one link for VS Code and one for Cursor (cursor:extension/anthropic.claude-code). We asked each official channel which of the three version numbers it lists. Times are UTC.

Two readings follow. Version 2.1.312 is real: Anthropic shipped it on October 27, and Cursor’s indicator list labels its 2.1.312 files “Modified VSIX,” so the altered files reuse a genuine release number. Version 2.1.313 matches no official release today. A missing page gives the same 404 whether a release never existed or was withdrawn, so we cannot say which. Phorion writes that Cursor was “additionally pulling NPM and VSCode versions for 2.1.313 from their relevant registries,” while OpenSourceMalware writes that the npm package, the Open VSX extension and Microsoft’s extension are “NOT malicious.” Neither says a genuine 2.1.313 ever existed. What the numbers do show is that 2.1.313 was the next number after the newest official release at the time, 2.1.312, so an update check would have read it as the next routine update. That last point is our inference, not a statement from any source.

We covered the same version-number problem earlier this month: tampered Rank Math PRO downloads carried a version its changelog had already announced, so the number could not show whether a site was affected.

What “would fail” covers

Cursor’s notice says: “Outside of highly unusual circumstances where Cursor was started with administrator privileges, due to errors in the malicious code, this step would fail.” The step is turning SSH on. The write-ups from Phorion and OpenSourceMalware show how much of the chain does not depend on it.

So the failure lands on one step, and it matters only if nothing was listening on port 22 already. As Phorion describes the design, the tunnel forwards to localhost:22 on the victim, so a machine that already ran an SSH server could be reached by whoever held the private half of the planted key and could connect to the tunnel server. Phorion: “If the user already had Remote Login enabled, or turns it on later, the backdoor is ready and waiting.” Cursor’s own scripts end with a check for exactly that case and print “note: something listens on localhost:22; the tunnel exposed it.” Cursor’s sentence “On those hosts the step fails and the attacker could not have logged in through the tunnel” is about hosts where SSH never came on. The server that took the tunnels and beacons is down (“The attacker server no longer functions”), but the key and the persistence scripts stay on any machine until someone removes them.

Who did what, and what nobody has said

Cursor’s notice says it “audited access and confirmed no other extensions were tampered with,” “rotated our keys, rebuilt the marketplace, and brought it back online,” and worked with the hosting provider to take the server offline. It does not say how the tampered files got in. OpenSourceMalware says Cursor told it that the extension in the marketplace “experienced some form of compromise.”

Anthropic’s position is in Rieseberg’s post on X: it “wasn’t a compromise of Anthropic’s systems or employee laptops,” “a malicious actor used access to Cursor’s marketplace to publish a tampered copy of the Claude Code extension, which we didn’t build or publish,” and “The versions on our official channels are not affected and this only impacts Cursor users.” The Register notes that “neither Cursor nor Anthropic have commented on how the malicious package made its way to the official marketplace,” and BleepingComputer lists “how the threat actors published a malicious extension under Anthropic’s name on Cursor’s marketplace” among the open questions.

Two details come from our own checks. The address in the indicators, 134[.]209[.]82[.]225, falls in 134.209.0.0/16, which ARIN’s RDAP record lists to DigitalOcean, LLC. That says who holds the block, not who rented the server, and Cursor names no provider. And Cursor’s list includes modified files for 2.1.312, a number Anthropic had released two days earlier, so the altered files reuse a genuine release number; from outside we cannot tell whether that points to an upload or to a change to stored files.

For comparison, in the LiteLLM 1.107.0 case the project said stolen tokens let attackers rewrite its own release workflow, so the poisoned build came from the vendor’s pipeline. Here Anthropic says its systems and official channels were not involved and that the access came through the marketplace operator.

Where the accounts differ

What to check now

The first checks come from Cursor’s notice and the rest are marked. We ran each against dummy folders on Windows 11 with Git Bash, Windows PowerShell 5.1 and OpenSSH 10.3 (ssh-keygen), not against a real infection. We read Cursor’s two remediation scripts and did not run them.

Look for the planted key

macOS or any Bash shell, from Cursor’s notice:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"

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" }

On our dummy files a clean authorized_keys printed No key found; machine not impacted, and both files carrying the attacker’s key printed svc-telemetry key found in both shells. For the PowerShell test we pointed the user-profile environment variables at a dummy folder so that $HOME resolved there; the command itself is unchanged.

List fingerprints, but do not rely on them alone

ssh-keygen -lf ~/.ssh/authorized_keys

Cursor and OpenSourceMalware publish the attacker key’s fingerprint, SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. We recomputed it from the published key (SHA-256 of the decoded key blob, base64 without padding) and it matches. Phorion advises checking the fingerprint “rather than relying solely on the comment string.” Our test shows the opposite risk too. The payload appends its key with no leading newline, so if the file did not end with one, the key lands at the end of the last line, and ssh-keygen reads it as part of that key’s comment. In our dummy file it listed only the real key’s fingerprint, with a comment that began dev@laptopssh-ed25519 AAAA and ended svc-telemetry, while the text search above still found it. Cursor’s scripts handle that layout: “It’s appended without a leading newline, so it may share a line with a real key.” We did not start an SSH server, so this is a result about OpenSSH’s key parser, not a test of whether a glued key can log in.

Check extension folders by content, not by version

The glob Cursor’s macOS script uses, with grep -l added by us (it matches .cursor, .vscode and any other dot folder with an extensions directory):

grep -l svc-telemetry ~/.[!.]*/extensions/anthropic.claude-code-*/extension.js

The same idea for Windows PowerShell (ours):

Get-ChildItem "$env:USERPROFILE\.*\extensions\anthropic.claude-code-*\extension.js" -Force -ErrorAction SilentlyContinue |
  Where-Object { Select-String -LiteralPath $_.FullName -Pattern svc-telemetry -SimpleMatch -Quiet } |
  ForEach-Object { "TAMPERED: " + $_.FullName }

Both flagged a dummy folder named anthropic.claude-code-2.1.312-win32-x64 whose extension.js contained the marker and stayed silent on an otherwise identical folder without it. A hit means the folder held the tampered bundle; no hit means this copy is clean, not that the machine never ran a tampered one.

Ask whether anything listens on port 22

Get-NetTCPConnection -LocalPort 22 -State Listen -ErrorAction SilentlyContinue

This is the call Cursor’s Windows script uses, and it printed nothing on our test machine. On macOS Cursor’s script runs nc -z -G1 127.0.0.1 22, which we could not run here. If something does listen and the key or the folder turned up, Cursor’s own wording is that the tunnel exposed it.

If anything turns up

Cursor’s steps: isolate hosts that show the payload or the backdoor, remove the key, the persistence and the tunnel processes, and decide whether to rebuild the machine. “Uninstalling the extension may not be sufficient,” because the payload drops scripts that keep running. Rotate credentials and sessions the machine could reach, from a trusted system, since “The limited env-var collection does not rule out later credential access over the backdoor.” Cursor’s macOS script (run as the affected user, without sudo) and Windows script (run in an elevated PowerShell with editors closed; it cleans every profile) automate the removal and exit non-zero if anything remains. From reading them: they stop the launchd job or the SysMon task and the tunnel processes, delete extension folders whose extension.js contains the marker, delete the dropped files and cut the key out of authorized_keys.

What is still unknown

• How the actor reached the marketplace. Cursor rotated its keys and rebuilt the marketplace but gives no cause, and Anthropic’s statement says only that a malicious actor “used access.”
• How many machines installed a tampered build. The archived versions of the notice gave a ceiling of 5,000, the current one gives none, and nothing public says whether the ceiling covered 2.1.312.
• Whether anyone logged in. No source reports a login over a tunnel. Cursor says most hosts could not have been reached; no source says how many ran an SSH server already.
• Whether Linux builds were served. Cursor lists Windows and macOS builds, Phorion found Linux code in the payload, and The Register says the backdoor was written for all three systems.
• Which version Cursor’s rebuilt marketplace serves now. Anthropic’s official channels list 2.1.314 as the newest build, but we could not read Cursor’s marketplace listing, and Cursor’s notice does not name a clean version.
• Why 2.1.313 is in no official channel, and whether a genuine release with that number ever existed.
• What would have come next. OpenSourceMalware found no downloader in the injected stage and notes that “Follow-on commands or files transferred after access would not appear in this static artifact.”

Sources and method

We read Cursor’s notice (the current page and the archived copies from 08:43 and 12:48 UTC), Phorion’s and OpenSourceMalware’s write-ups, BleepingComputer’s story, The Register’s story, Rieseberg’s post, both of Cursor’s remediation scripts and Anthropic’s VS Code documentation. On October 30 we queried the npm registry, GitHub’s API (releases and tags for anthropics/claude-code) and its changelog, Open VSX’s API, the Visual Studio Marketplace’s public query API, ARIN’s RDAP service for the address, and the Wayback Machine’s index. The window length, the weekdays and the gaps between release times are our arithmetic. We recomputed the key fingerprint from the published key and ran the checks above on dummy files. We did not download the tampered extension, run any payload or remediation script, contact the attacker’s address, or test anything inside an editor, so every statement about what the code does rests on Cursor’s, Phorion’s and OpenSourceMalware’s descriptions of it.