Tampered Claude Code extension on Cursor tried to plant SSH backdoors for about 11 hours, with no crypto theft reported

A tampered copy of the Claude Code extension, listed under Anthropic’s name on Cursor’s own marketplace, tried to plant an SSH backdoor on developer machines for about 11 hours on 29 October 2026, Cursor said in a security notice. No crypto theft has been reported, and no source says that a wallet was touched or that the value of any secret left a machine.

The affected versions are Anthropic.claude-code 2.1.312 and 2.1.313 for Windows and macOS, distributed through the Cursor VS Code Extension Marketplace between about 2:27am and 1:35pm Pacific time. That is 09:27 to 20:35 UTC: the US was still on daylight time (UTC-7) that Thursday, and The Register gives the same UTC times. Cursor says these versions were “not developed by Anthropic.”

Crypto developers have a reason to look closer if they ran those versions. CryptoSlate notes that Cursor’s advice would extend to development or financial-service credentials on the affected account, if present. On the evidence published, the code went after remote access rather than funds, and clean-up goes further than the extension itself: Cursor warns that “Uninstalling the extension may not be sufficient.”

How the Claude Code extension backdoor worked on Cursor

The endpoint-security vendor Phorion, which The Register says spotted the backdoor first, published a detailed analysis, and Cursor’s notice matches it on the main stages. BleepingComputer also credits researchers at OpenSourceMalware. Extra code sat at the front of the minified extension.js file and ran as soon as Node loaded that file, before the extension activated, so nobody had to click anything. According to Cursor and Phorion, it then went through these stages:

1. It appended an attacker-controlled Ed25519 key, with the comment svc-telemetry, to the user’s authorized_keys file.
2. It tried to switch on the local SSH service. This used no exploit, so it needs administrator rights or passwordless sudo. Cursor says the extension lacks those rights on most macOS and Windows hosts, where the step fails.
3. It tried to open a reverse SSH tunnel to the server at 134.209.82.225, retrying roughly every 60 seconds and detached from the editor, so closing Cursor would not stop it.
4. It set up persistence: a LaunchAgent on macOS, a scheduled task named SysMon on Windows with a Startup-folder fallback, and an @reboot cron entry on Linux.
5. It sent a one-off report about the machine to the same server over plain HTTP.

A reverse tunnel runs in the opposite direction from a normal remote login. The infected machine dials out to the attacker’s server, and that outgoing connection is what an operator would later use to reach back in. Cursor’s notice limits the affected packages to Windows and macOS, although its indicators also list Linux files, and Phorion describes a Linux code path.

The code also had bugs, Phorion found. On macOS the script checks Remote Login without root rights, receives an error rather than the word “Off” and skips the enable step, yet the key and the persistence still land on disk. Inbound access through the tunnel then fails unless Remote Login was already on. Phorion stresses that this is no defence, since the backdoor works if the setting is turned on later. On Windows, a helper hardcodes /bin/sh, which the firm says is unlikely to work on a standard install. On Linux, a faulty crontab check can wipe existing user cron jobs on repeat runs.

Cursor’s conclusion is that on hosts where enabling SSH failed, the attacker “could not have logged in through the tunnel”. The same passage says the extension still added the key, installed persistence and sent host details, and it tells users to follow the remediation steps regardless.

The report sent environment variable names, not their values

Phorion lists what the report carried: hostname, username, operating system and architecture, home and working directories, the global Git email, the public IP address, status flags for each setup stage, and up to 40 environment variable names matching KEY, TOKEN, SECRET, PASS, AWS or GCP. Cursor’s own list agrees on the names, the working directories, the Git email and the public IP.

Phorion is explicit that the report took names only: the beacon “doesn’t exfiltrate the secret values themselves,” it wrote. No source reviewed for this article says a value was sent.

Names still say something. Phorion reads them as an inventory that helps an operator decide which machines to prioritise. Take two names we made up for illustration, which appear in no source: a variable called DEPLOYER_PRIVATE_KEY or EXCHANGE_API_SECRET would mark a machine as worth a closer look, though the report would carry only the name.

That limit applies to the report and not to whatever the backdoor could have allowed afterwards. Cursor says so itself: “The limited env-var collection does not rule out later credential access over the backdoor.” BleepingComputer notes that the script does not directly steal credentials and reads this as a sign the attackers meant to collect sensitive data by hand after getting in. No source we read reports a case of such access.

How the package reached the marketplace is still unexplained

Cursor’s notice does not say how the tampered package came to be published under Anthropic’s name. The Register reported on 30 October that, beyond the statement below, neither Cursor nor Anthropic had commented on it. BleepingComputer listed the same question as unanswered, along with whether Cursor’s or Anthropic’s systems were compromised. No source we read names an attacker either.

Anthropic’s position reaches us second-hand. The Register reported that Felix Rieseberg, a member of Anthropic’s technical staff, wrote on X: “We’re working with Cursor on this incident, but it wasn’t a compromise of Anthropic’s systems or employee laptops.” According to the same report, he added that “A malicious actor used access to Cursor’s marketplace to publish a tampered copy” of the extension, one Anthropic “didn’t build or publish”, that versions on its official channels were not affected and that only Cursor users were. Coindaro has not read the post itself.

That is Anthropic’s own account, and no source we read confirms it independently. It also leaves open how the access to the marketplace was obtained, and by whom. Reuters, in a dispatch carried by the Gulf Daily News, said Anthropic did not immediately respond to a request for comment, and BleepingComputer said it had contacted both companies and would update its story if they replied.

The Register says the post answered cybersecurity figures who had alleged a breach at Anthropic; it does not name them or set out their evidence. Cursor’s notice carries no statement from Anthropic. Phorion calls the listing the official extension on the Cursor Marketplace, and no source we read explains who controlled publishing to it.

Cursor describes its own response in the notice. It removed the malicious version, blocked further distribution and temporarily shut the marketplace. It then audited access, says no other extensions were tampered with, rotated keys, rebuilt the marketplace and brought it back. It also worked with the hosting provider and says the attacker’s server is offline. It reports no evidence that other versions of the extension or the official distribution were affected. As with Anthropic’s account, these are the company’s own statements. An offline server does not clean a machine, though: on the code described above, the key and the retry jobs stay until someone removes them.

The scope moved in the first two days, so older articles may be wrong. Early reports named npm, Open VSX and Microsoft’s Visual Studio Code Marketplace; BleepingComputer says it was later confirmed that Cursor was the only source. Phorion corrected its own post to name the Cursor marketplace on 30 October at 09:13 UTC. It first named only 2.1.313 and added 2.1.312 on 31 October at 00:43 UTC, after Cursor updated its notice on 30 October at 11:30am Pacific time (18:30 UTC). The Register and BleepingComputer still give 2.1.313 alone.

The number of people affected is not established. Reuters reported on 30 October that Cursor said up to 5,000 users were affected. The Register and BleepingComputer print “up to 5,000 developers” without a source, the first saying infected and the second exposed. Cursor’s notice, which we reopened on 2 November, gives no count, so treat that number as unverified.

What to check: Cursor’s steps for affected machines

Cursor’s advice applies to anyone who installed or updated to those versions from its marketplace on macOS or Windows during the window. It says the key and the persistence went in even on hosts where enabling SSH failed, so a failed SSH step is no reason to skip the check. In short, the notice asks users to:

1. Check for the key. On macOS Cursor gives this command: grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted". Its Windows check is a PowerShell search of the authorized_keys files, printed in the notice.
2. Search endpoint, network and extension-installation logs for the published indicators.
3. Isolate any host that shows the payload ran or the backdoor was installed.
4. Remove the unauthorized key, the persistence and the tunnel processes, then decide whether to rebuild the host.
5. Rotate credentials and sessions reachable from affected hosts, working from a trusted system.

If the key is found, Cursor says the machine is impacted: steps 3 to 5 apply, and so does its clean-up script. There is one for macOS, run as the affected user and not as root, and one for Windows, run from PowerShell as Administrator. Each exits with a non-zero status if anything remains. The notice gives no Linux check or script; Phorion’s remediation list covers the Linux items. Questions go to [email protected].

The main indicators below come from Cursor’s notice, and Phorion’s write-up matches them. The file hashes and SSH key fingerprints are in the notice. Phorion advises checking the fingerprint as well as the comment.

Two services the code used to find the public IP, ifconfig.me and api.ipify.org, are legitimate and prove nothing alone. To see whether anyone actually used a backdoor, Phorion says to look in SSH logs for logins from 127.0.0.1 or ::1 made with that key, because tunnelled sessions appear to come from the machine itself. It also says to terminate the /bin/sh retry loop and to verify that Remote Login has not been switched on unexpectedly.

The two write-ups differ on credentials. Cursor tells affected hosts to rotate what they can reach. Phorion ties rotation to SSH having been enabled or to evidence of an inbound login. Cursor’s is the stricter of the two.

Our own advice for crypto developers, on top of Cursor’s

This section is Coindaro’s, not Cursor’s or Phorion’s, and it is general hygiene, not incident response. It would hold with or without this incident.

• Keep seed phrases and the private keys that control real funds off development machines, in the way our guide to seed phrase security describes.
• Use throwaway keys for testing, so a leaked test key holds nothing of value.
• Give exchange API keys the narrowest rights the job allows and leave withdrawals off where the exchange offers that choice.
• Download any clean-up script from the vendor’s own page, never from a copy passed around in a chat or a forum.

A trusted channel again, but no reported loss this time

Coindaro has covered several recent attacks that came through a third party rather than through a blockchain, the pattern set out in our guide on where crypto hacks really happen. This case shares the route but not the outcome so far. The figures in the table are those reported in each of our earlier articles.

Fearless Wallet is the closest in form, since both are extensions, yet the difference is what matters: that one took private keys directly, while this one, on the evidence so far, took environment variable names and tried to open a door. CryptoSlate says neither advisory it reviewed establishes crypto theft or crypto-specific targeting. Developers’ machines were the target here, and no source we read links the incident to any known group or to other recent hacks.

What nobody has answered yet

Several questions remain open as of 2 November. Neither Cursor nor Anthropic has explained how the attacker obtained the access to publish the package, and no install count has been confirmed at source. No source we read reports a machine actually entered through a tunnel, or a credential taken. Phorion says it is not clear why the report also went to a local address, 127.0.0.1 on port 8099.

Cursor last updated its notice on 30 October and Phorion its analysis on 31 October. Neither page showed anything newer when we checked on 2 November.