Backdoored Claude Code extension: what to check

What happened to the Claude Code extension in Cursor

The Claude Code extension backdoor came from one place: Cursor's own extension marketplace, which served tampered builds 2.1.312 and 2.1.313 of Anthropic.claude-code on 29 October 2026. If you used Cursor on macOS or Windows that day, search your authorized_keys file for the label svc-telemetry. If the key is there, run Cursor's cleanup script. Then replace every SSH key your servers trust, and do it from a clean machine, because anyone who used that planted key could read your private keys.

Cursor published its notice on 29 October. It updated the notice on 30 October at 11:30 am PT: "We updated the IOCs and clarified affected versions." The notice states these facts:

• When and where: "Between about 2:27am PT and 1:35pm PT today, a maliciously modified version of Anthropic's Claude Code extension was made available in the Cursor VS Code Extension Marketplace."
• Which builds: "Anthropic.claude-code version 2.1.312 and 2.1.313 for Windows and MacOS".
• Who built them: "These malicious versions of the extension were not developed by Anthropic."
• What else is affected: "We have no evidence that other versions of the extension or the official distribution are affected."

Some early reports named Open VSX or the Visual Studio Marketplace as the source. Cursor's notice does not mention Open VSX. Microsoft published its own write-up on 30 October. It says the tampered copy was "available and served in the Cursor extension marketplace for a few hours" and that the malicious packages "were never published nor distributed from Microsoft Visual Studio Marketplace."

Cursor's notice does not name a fixed version. As of 31 October 2026, the Open VSX registry lists Claude Code versions 2.1.316, 2.1.314 and 2.1.312, plus older versions. It does not list 2.1.313. That list shows what Open VSX holds today. Neither Cursor nor Anthropic has used it to say that any particular build is safe.

What the tampered extension did

The notice lists the behaviour. The extension:

• Appends the attacker's public key, labelled svc-telemetry, to your SSH authorized_keys file.
• Tries to turn on the local SSH service and opens a reverse SSH tunnel to tunnel@134[.]209[.]82[.]225 on TCP port 22.
• Installs persistence: a LaunchAgent named com.apple.sysmond on macOS, and a scheduled task named SysMon on Windows, with a sysmon.cmd file in the Startup folder as a fallback.
• Collects host and user information (hostname, username, OS, architecture, home directory path and environment information) and sends a beacon by HTTP POST to port 8099 on the same address.

The reverse tunnel matters because of its direction. Your laptop dials out to the attacker's server and holds that connection open. The attacker can then send an SSH login back down the open connection. Your home router and its NAT (network address translation) never see a new inbound connection, so they have nothing to block.

Two facts from the notice limit the damage. Cursor says the attacker server no longer functions. It also says that "turning on the local SSH service requires admin rights", "which the malicious extension does not have on most macOS and Windows hosts." So on many machines the SSH step failed. Cursor still tells everyone who installed these builds to follow its remediation steps. We agree, because the check takes seconds.

The indicators of compromise (IOCs)

An IOC (indicator of compromise) is a file, address or string that shows an attack reached a machine. The notice writes addresses in defanged form, with [.] in place of each dot, so nobody clicks them by accident. The commands in this guide search for the svc-telemetry string rather than the address.

• macOS: ~/Library/LaunchAgents/com.apple.sysmond.plist (label com.apple.sysmond), $TMPDIR/.stk_<10 hex>, ~/.config/.smt, ~/.config/.smtk, and the unauthorized key in ~/.ssh/authorized_keys.
• Windows: %USERPROFILE%\.ssh\authorized_keys, %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_<10 hex>, the scheduled task SysMon (it attempts to run as SYSTEM), and the fallback %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd.
• Linux: /tmp/.stk_<10 hex> and a cron entry @reboot /bin/sh "<HOME>/.config/.smt".
• Network: the external beacon hxxp://134[.]209[.]82[.]225:8099/beacon and reverse SSH as tunnel@134[.]209[.]82[.]225 on TCP 22. Cursor notes that lookups to ifconfig.me and api.ipify.org are legitimate and are not an indicator on their own.
• The planted key: ssh-ed25519 with the comment svc-telemetry, fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.

The notice also lists SHA-256 hashes for each malicious VSIX package and for the payload extension.js. If you need them for a detection rule, copy them from the Cursor security notice itself. One wrong character makes a hash useless.

Am I affected? A short checklist

Work through these steps in order on each Mac or Windows machine where you run Cursor.

1. Check whether Cursor had the Claude Code extension installed on 29 October and updated extensions that day. If you are not sure, keep going.
2. Find out whether the tampered build is still on disk.
3. Look for the svc-telemetry key.
4. Look for the persistence files.
5. If anything turns up, run Cursor's remediation script and move on to your servers.

Is the tampered build still installed?

Cursor does not document where it keeps extensions on disk, so do not trust a path from a forum post. In Cursor, open the Extensions view and select Claude Code to see the version it reports. To check the files themselves without guessing a path, search your home folder for the extension's folder:

find ~ -maxdepth 4 -type d -iname 'anthropic.claude-code*' 2>/dev/null

Cursor says the modified extension.js contains both the attacker's address and the string svc-telemetry. This command searches every folder the first command found for that string:

find ~ -maxdepth 4 -type d -iname 'anthropic.claude-code*' -exec grep -rlF svc-telemetry {} + 2>/dev/null

No output means the string is not inside any Claude Code extension folder. A printed file path means a tampered copy is still on disk. On Windows, the same search in PowerShell is:

Get-ChildItem $HOME -Directory -Recurse -Depth 3 -Filter 'anthropic.claude-code*' -ErrorAction SilentlyContinue | ForEach-Object { Get-ChildItem $_.FullName -Recurse -File -Filter extension.js | Select-String -SimpleMatch 'svc-telemetry' -List }

A clean extension folder does not prove a clean machine. The extension may have updated past the bad build since 29 October, and the key and persistence files would still be there. Run the next two checks either way.

Is the svc-telemetry key in authorized_keys?

These are Cursor's own commands. On macOS:

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

On Windows, run this in PowerShell:

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

The notice is direct about the result: "If the key is found, your machine is impacted." Compare these commands with the live notice before you run them, in case Cursor has changed them since.

Are the persistence files there?

On macOS:

ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk
ls -la "$TMPDIR"/.stk_*

An error for every path means none of the files exist. On Windows:

Test-Path "$env:USERPROFILE\.config\smt.cmd", "$env:USERPROFILE\.config\smtk", "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Get-ScheduledTask -TaskName SysMon -ErrorAction SilentlyContinue

Test-Path prints one True or False per path, so you want three False lines. Get-ScheduledTask prints nothing when no task called SysMon exists.

Run Cursor's remediation script

Cursor publishes two scripts on the notice page. Download remediate-macos.sh and run it as the affected user, not as root. Download remediate-windows.ps1 and run it from PowerShell opened with Run as Administrator. Cursor says the scripts remove the malicious extension, the persistence mechanisms and the running tunnel processes. Read any script before you run it, the same way you would on a server. Then follow the rest of Cursor's list. Search your telemetry for the IOCs, isolate any host that shows the payload ran or the backdoor was installed, and decide whether to rebuild that host.

Why uninstalling the extension is not enough

Removing the extension deletes the extension's own folder. The planted key is a line in ~/.ssh/authorized_keys. The persistence scripts sit in ~/.config, your temp folder and your login items. None of them live in the extension folder, so they stay after an uninstall. Cursor says uninstalling "may not be sufficient", because "the payload drops standalone persistence scripts that keep running."

Why your servers are the real problem

This section is our reasoning. It is not a claim from Cursor's notice. If the svc-telemetry key was found and the SSH step worked, the attacker could log in to your laptop as you. An SSH login as you can read every file you can read. That includes:

• Your private keys in ~/.ssh/, such as id_ed25519.
• ~/.ssh/config, which lists your servers with their host names, users and ports.
• ~/.ssh/known_hosts, which records every host you have connected to.
• Your SSH agent, if it is running with keys loaded. A passphrase slows down use of a stolen key file. It does not help while the agent holds the key unlocked.

Now think about what your server logs would show. An attacker who connects to your servers from your laptop arrives from your IP address, as your user, with your key. The log line looks the same as one of your own logins. So a search of server auth logs for unfamiliar IP addresses can come back clean and prove nothing. Cursor's step 5 points the same way: "Rotate credentials and sessions accessible from affected hosts, from a trusted system."

Cursor also lists "environment" among the information the payload collected. If your shell environment holds API tokens or cloud credentials, treat them as exposed and rotate them too. The habits that limit this kind of exposure are covered in keeping secrets out of AI coding agents.

How to rotate SSH keys from a clean machine

A clean machine is one that never ran the tampered build. A different computer is best. Do not copy the old private key onto it.

On the clean machine, create a new key pair and give it a passphrase:

ssh-keygen -t ed25519 -C "clean-machine-2026-10-31"
cat ~/.ssh/id_ed25519.pub

Next, reach each server without the old key. Use your VPS provider's web console, or ask a second admin who was not affected. Then, on each server, look for the attacker's key in every user's authorized_keys, not only your own:

sudo grep -rn -e svc-telemetry -e AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P /root/.ssh /home/*/.ssh 2>/dev/null

No output means the planted key is not on that server. Then open each authorized_keys file and read every line:

sudo nano /home/youruser/.ssh/authorized_keys

Delete the line for the old laptop key. It holds the same text as the old laptop's .pub file. Delete any line you cannot account for. Paste in the new public key and save. Before you close the console session, open a second terminal on the clean machine and confirm the new key logs in, because a typo in this file locks you out.

Repeat this for every server listed in your old ~/.ssh/config. Then remove the old key from each Git host account and from any deploy keys, and add the new one. For a fuller routine on naming, storing and retiring keys, see SSH key management basics.

Check server logs, and know what they cannot tell you

On Ubuntu the OpenSSH unit is ssh.service. List recent logins, then read the SSH log since the day of the incident:

last -i | head -n 50
sudo journalctl -u ssh.service --since "2026-10-29 00:00:00"

last reads the system login record, and -i prints IP addresses instead of host names. Look for sessions at hours when you were not working, and for logins as users you never use. If your distribution names the unit differently, systemctl list-units '*ssh*' shows the right name.

Remember the limit from the section above. A suspicious entry is evidence. A clean log is not proof, because a login made from your own laptop looks like one of yours. If you find something you cannot explain, stop treating this as a key rotation and follow what to do if your VPS is hacked.

Check servers you connected to from Cursor

Cursor has not said whether Linux builds received a tampered package. It has also not said whether servers you opened from Cursor over SSH did. The notice scopes the incident to Windows and macOS. Its IOC list still includes Linux entries: /tmp/.stk_<10 hex> and a cron entry that runs ~/.config/.smt at boot. The check takes about ten seconds, so run it on every server you reached from Cursor:

sudo grep -rnF -e .config/.smt -e svc-telemetry /var/spool/cron /etc/crontab /etc/cron.d 2>/dev/null
sudo find /root /home /tmp -maxdepth 3 \( -name .smt -o -name .smtk -o -name '.stk_*' \) 2>/dev/null

No output from either command means none of these Linux IOCs are present. Add the authorized_keys search from the rotation section, and you have covered every Linux indicator in the notice.

What the official publisher ID did not protect

The extension carried the real publisher ID, Anthropic.claude-code. The code was changed at the point of distribution, so checking the publisher name protected nobody. Anthropic's own docs say it plainly: "Extension marketplaces are third-party software, which Anthropic doesn't endorse, maintain, or audit." Cursor's help pages say it uses the Open VSX registry for third-party extensions and routes extension search and downloads through its own marketplace proxy. These builds were served through that marketplace.

Cursor's enterprise docs describe an AllowedExtensions policy that "Controls which extensions can be installed", by publisher or extension ID. An allowlist that trusted Anthropic would have let these builds through, because they carried Anthropic's ID. The control that helps is time. Cursor's help pages say admins can defer extension installs and updates until a marketplace version has been published for a period. This build was pulled on the same day it appeared, so a short delay would have skipped it.

For a single machine, VS Code documents that it "checks for extension updates and installs them automatically". It also has an extensions.autoUpdate setting and an auto-update toggle on each extension. Cursor is built on VS Code, but Cursor's docs do not describe these settings, so look in Cursor's Settings for the same option before you rely on it. If it is there, this line in your user settings turns automatic extension updates off:

"extensions.autoUpdate": false

After a security notice, leave auto-update off for a week. Update by hand once the vendor names a good version. The same pattern, a trusted name carrying a tampered build, shows up in package registries, and npm supply chain attacks on a server covers the server-side version of this problem. If you are deciding where Claude Code should run at all, comparing Claude Code with Cursor, Codex and Copilot sets out how each tool fits into your work.

FAQ

Am I affected if I use Claude Code in VS Code or the terminal, not Cursor?

Cursor's notice covers builds served by the Cursor VS Code Extension Marketplace. Cursor says it has "no evidence that other versions of the extension or the official distribution are affected." Microsoft says the malicious packages were never published or distributed from the Visual Studio Marketplace. The svc-telemetry check still takes seconds, so run grep -qs svc-telemetry ~/.ssh/authorized_keys && echo found if you want to be sure.

Does uninstalling the Claude Code extension remove the backdoor?

No. The planted SSH key is a line in ~/.ssh/authorized_keys. The persistence scripts live in ~/.config, the temp folder, a macOS LaunchAgent or a Windows scheduled task. None of these are inside the extension folder. Cursor says uninstalling "may not be sufficient" and provides remediate-macos.sh and remediate-windows.ps1 to remove the extension, the persistence and the tunnel processes.

Which Claude Code extension version is safe to install?

Cursor's notice names 2.1.312 and 2.1.313 as malicious and does not name a fixed version. Check the vendor's own release notes before you install a specific version, and keep automatic extension updates off until you have.

Why rotate my SSH keys if my server logs look clean?

If the planted key worked, the attacker could log in to your laptop as you. That gives them your private keys, your ~/.ssh/config host list and your loaded SSH agent. Logins made from your laptop arrive from your IP address with your key, so they look like your own sessions in the server log. Create a new key on a clean machine and replace the old public key in every authorized_keys file and Git host. Then review last -i and journalctl -u ssh.service.

Do I need to check my Linux servers?

Cursor has not said whether Linux builds, or servers you opened from Cursor over SSH, received a tampered package. It scopes the incident to Windows and macOS. Its IOC list still names /tmp/.stk_<10 hex>, ~/.config/.smt and an @reboot cron entry for Linux. Grep /var/spool/cron, /etc/crontab and every authorized_keys file for svc-telemetry and .smt. It takes about ten seconds per server.