Claude Code VS Code Extension 2.1.313 Shipped an SSH Backdoor: a 5-Minute Check and Cleanup for Cursor / VSCodium Users

Short version: According to the October 30 analyses by OpenSourceMalware and Phorion, the Claude Code for VS Code extension published to Open VSX as anthropic.claude-code@2.1.313 contained a backdoor. It leaves an attacker SSH key, a reverse tunnel to 134.209.82.225 and boot-time persistence on your machine. According to Phorion, Anthropic has pulled 2.1.313 from Open VSX, npm and the VS Code Marketplace; according to Sesame Disk, the current Open VSX release is 2.1.314.

Uninstalling the extension does not remove the backdoor. If you use Cursor, VSCodium, Windsurf or another editor that installs extensions from Open VSX, and you installed or auto-updated the Claude Code extension today, run the 5 steps below.

We ran every check command below on a Linux machine. The whole set finished in under 1 second with normal output. We did not install the malicious version on any machine.

What happened

According to OpenSourceMalware:

• The malicious build identifies itself as anthropic.claude-code 2.1.313. Unpacked, it matches the normal release and ships the official binary. Only extension.js differs: a 66-line immediately invoked function sits in front of the real extension code.
• You don't have to start a Claude conversation. Loading the extension module is enough. The package has no install or postinstall scripts, so it fires at runtime.
• Almost every exception is swallowed, so the extension keeps working and nothing looks wrong.

According to RuntimeWire, security researcher Adnan Khan (@adnanthekhan) first flagged it publicly on X. See also this post by @mattjay on X.

What the backdoor does

According to OpenSourceMalware and Phorion, the loader does the following:

1. Adds a key: creates ~/.ssh and appends an Ed25519 public key with the comment svc-telemetry and fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk to ~/.ssh/authorized_keys. Whoever holds the matching private key can log in as you.
2. Tries to enable SSH: on Linux it starts sshd / ssh via systemctl and fallbacks; on macOS it tries sudo -n systemsetup -setremotelogin on; on Windows it uses PowerShell to install and start OpenSSH Server.
3. Reverse tunnel: writes a second embedded private key (comment svc-telemetry-tun) to a .stk_* file in the temp directory and connects as user tunnel to 134.209.82.225:22 with -R '*:0:localhost:22', retrying every 60 seconds and preferring autossh when present.
4. Persistence: on macOS it writes ~/.config/.smt, ~/.config/.smtk and ~/Library/LaunchAgents/com.apple.sysmond.plist (named like an Apple component, but it is not); on Linux the same two files plus an @reboot crontab line; on Windows .config\smt.cmd and .config\smtk, a scheduled task named SysMon, or sysmon.cmd in the Startup folder as a fallback.
5. Host beacon: after 1.5 seconds it POSTs hostname, username, OS, architecture, directories, Git email and up to 40 environment variable names matching KEY/TOKEN/SECRET/PASS/AWS/GCP over plain HTTP to 134.209.82.225:8099/beacon. Both analyses say names are sent, not values.

According to Phorion, there is a macOS bug: as a standard user, systemsetup -getremotelogin never returns Off, so the script skips enabling Remote Login. The key and persistence are still written, and the backdoor works as soon as Remote Login is on. Mac users should check too.

What is still unknown

• How the malicious build was published: public reports have not said yet. According to OpenSourceMalware, the Open VSX extension is owned by an Anthropic employee, but whether that account or another part of the publishing process was compromised, public reports have not said yet.
• Whether Microsoft's VS Code Marketplace ever served this version: public reports have not said yet. According to Sesame Disk, the Marketplace's public version history does not list 2.1.313; OpenSourceMalware filed a precautionary threat report for the Marketplace version as well.
• Who the attacker is and who controls 134.209.82.225: public reports have not said yet.

Create an API Key and swap in a new Claude Code / Codex key after your check →

Step 1: Check the extension version and move to 2.1.314 or later

macOS / Linux terminal:

code   --list-extensions --show-versions | grep -i anthropic.claude-code
cursor --list-extensions --show-versions | grep -i anthropic.claude-code
codium --list-extensions --show-versions | grep -i anthropic.claude-code
ls -d ~/.vscode/extensions/anthropic.claude-code-* \
      ~/.cursor/extensions/anthropic.claude-code-* \
      ~/.vscode-oss/extensions/anthropic.claude-code-* \
      ~/.windsurf/extensions/anthropic.claude-code-* 2>/dev/null

Windows PowerShell:

Get-ChildItem "$env:USERPROFILE\.vscode\extensions","$env:USERPROFILE\.cursor\extensions","$env:USERPROFILE\.vscode-oss\extensions" -Filter "anthropic.claude-code-*" -ErrorAction SilentlyContinue | Select-Object Name

If you see anthropic.claude-code@2.1.313 or a directory with 2.1.313 in its name, that version was installed. Don't just delete it; go through steps 2 to 4 and then step 5. Even without 2.1.313, pin the extension to 2.1.314:

code   --install-extension anthropic.claude-code@2.1.314 --force
cursor --install-extension anthropic.claude-code@2.1.314 --force
codium --install-extension anthropic.claude-code@2.1.314 --force
claude --version

The last line shows your Claude Code CLI version. According to Phorion, 2.1.313 was also pulled from npm; if you see 2.1.313, upgrade it too.

Step 2: Audit authorized_keys by fingerprint, not just the comment

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

The first line searches by comment; the second and third by fingerprint. According to Phorion, the malware only checks whether the svc-telemetry comment exists, so use the fingerprint when hunting: comments are trivial to change. In a demo file we placed one of our own keys and the attacker key with its comment renamed to renamed. grep svc-telemetry matched 0 lines, while ssh-keygen -lf still listed the fingerprint:

256 SHA256:fcpk2HR713pxnLll4jbnb7Bu9k5gvtf8n7UREAQe1dI me@laptop (ED25519)
256 SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk renamed (ED25519)

Beyond that fingerprint, you should recognize every line ssh-keygen -lf prints. Treat anything unfamiliar as suspicious. On Windows:

Select-String -Path "$env:USERPROFILE\.ssh\authorized_keys" -Pattern "svc-telemetry"
ssh-keygen -lf "$env:USERPROFILE\.ssh\authorized_keys"

Step 3: Look for connections to 134.209.82.225 and tunnel processes

# macOS
lsof -nP -i @134.209.82.225
pgrep -fl 'localhost:22|\.smtk|\.stk_'
# Linux
ss -tnp | grep 134.209.82.225
pgrep -af 'localhost:22|\.smtk|\.stk_'

Windows:

Get-NetTCPConnection -RemoteAddress 134.209.82.225 -ErrorAction SilentlyContinue
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'localhost:22|smtk' } | Select-Object ProcessId,CommandLine

Any connection to 134.209.82.225, or an ssh / autossh process whose command line includes localhost:22, .smtk or .stk_, almost certainly means the machine is affected. According to Phorion, the tunnel runs detached, so closing the editor does not stop it.

Step 4: Check persistence and whether SSH was turned on

macOS:

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

Linux:

crontab -l | grep -n smt
ls -la ~/.config/.smt ~/.config/.smtk /tmp/.stk_* 2>/dev/null
systemctl is-enabled ssh sshd 2>/dev/null
systemctl is-active  ssh sshd 2>/dev/null

Windows:

Get-ScheduledTask -TaskName SysMon -ErrorAction SilentlyContinue
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Get-ChildItem "$env:USERPROFILE\.config" -Force -ErrorAction SilentlyContinue | Where-Object Name -match 'smt'
Get-Service sshd -ErrorAction SilentlyContinue

If any of com.apple.sysmond.plist, ~/.config/.smt, an @reboot line mentioning .smt, a SysMon task or sysmon.cmd in Startup exists, treat the machine as affected. Also look at the SSH service: if you never enabled remote login and it is on now, that is suspicious too.

Step 5: If you were hit

Following the guidance from OpenSourceMalware and Phorion:

1. Disconnect first and block 134.209.82.225 on ports 22 and 8099 at the firewall or router.
2. Preserve evidence before cleaning up:

mkdir -p ~/ir-evidence
cp -p ~/.ssh/authorized_keys ~/ir-evidence/ 2>/dev/null
cp -p ~/.config/.smt ~/Library/LaunchAgents/com.apple.sysmond.plist ~/ir-evidence/ 2>/dev/null
crontab -l > ~/ir-evidence/crontab.txt 2>/dev/null
ps auxww > ~/ir-evidence/ps.txt

1. Stop the tunnel and remove persistence and the key (macOS / Linux):

pkill -f '\.config/\.smt'
pkill -f 'localhost:22'
# macOS
launchctl unload -w ~/Library/LaunchAgents/com.apple.sysmond.plist
rm -f ~/Library/LaunchAgents/com.apple.sysmond.plist
# Linux
crontab -l | grep -v '\.smt' | crontab -
# macOS + Linux
rm -f ~/.config/.smt ~/.config/.smtk "${TMPDIR:-/tmp}"/.stk_*
sed -i.bak '/svc-telemetry/d' ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

sed removes lines by comment only. If step 2 found a renamed line by fingerprint, open ~/.ssh/authorized_keys and delete it by hand. Windows:

Unregister-ScheduledTask -TaskName SysMon -Confirm:$false -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd" -ErrorAction SilentlyContinue
Remove-Item "$env:USERPROFILE\.config\smt.cmd","$env:USERPROFILE\.config\smtk" -ErrorAction SilentlyContinue

1. Rotate every credential this machine could reach: SSH private keys, Git / GitHub tokens, AWS / GCP keys, tokens in .env files, and the API keys used by Claude Code and Codex. Rotate from a separate clean machine. According to Phorion, if SSH was ever enabled, or SSH logs show logins from 127.0.0.1 / ::1 using the svc-telemetry key, the attacker may already have been in, and this step is mandatory.
2. Turn off extension auto-update and consider rebuilding the machine. According to OpenSourceMalware, once an operator has logged in, the known files may not be the whole story, and a rebuild is safer than removing known artifacts.

If you use a key from this site, delete the old key in the console, create a new one, then update the value in the global ~/.claude/settings.json and ~/.codex/config.toml.

Create an API Key to replace any key that may have been exposed →

How to prevent this next time

• Pin extension versions and disable auto-update. Add to your editor settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

When a new version ships, wait a day or two and watch the security community before upgrading.

• Prefer the official CLI for Claude Code and rely less on editor marketplaces:

curl -fsSL https://claude.ai/install.sh | bash
claude --version

For install and third-party API setup, see the Claude Code third-party API setup guide.

• Know the permission boundaries of extensions, plugins and MCP: an editor extension runs with your full permissions and can read local files, terminals and credentials. See Codex Plugin, Skill, MCP and Internet Access boundaries and the Codex automation and Playwright MCP security guide.
• Audit your own projects regularly, for example with the Cloudflare security-audit skill for Claude Code.
• Don't leave keys in environment variables visible to every process. For how to swap keys, see Codex API Key configuration.

Sources

• OpenSourceMalware: Trojanized Claude Code Extension Plants an SSH Backdoor
• Phorion: Official Claude Code Extension Compromise: Security Advisory
• Sesame Disk: Claude Code extension SSH backdoor
• RuntimeWire: Trojanized Claude Code extension on Open VSX
• @mattjay on X