Claude Code Extension Compromised: What to Do

Yes, a Claude Code extension build was compromised, but only one: Anthropic.claude-code version 2.1.313 as served by Cursor's extension marketplace on October 29, 2026, from about 5:27 AM to 4:35 PM ET. Cursor says the build was not made by Anthropic, reached at most 5,000 users, and tried to plant an attacker SSH key, open a reverse SSH tunnel and install persistence. If you use Cursor and the extension updated that day, check ~/.ssh/authorized_keys for a key labeled svc-telemetry. If it is there, treat the machine as compromised, run Cursor's cleanup script, then rotate every credential the machine could reach. Updating to 2.1.314 alone does not remove the backdoor.

This guide pulls together what is confirmed, what is still disputed, the checks you can run in under a minute, and the habits that make the next poisoned extension less dangerous. Facts come from Cursor's security notice, the technical writeups by OpenSourceMalware, Phorion and StepSecurity, and our own registry checks, all read between 7:40 and 8:00 AM ET on October 30. Anthropic had not published a statement when we checked, so watch the Claude Code changelog and Cursor's notice for updates.

Was the Claude Code extension compromised? What is confirmed

So the terminal CLI you install with npm or the native installer is not part of this. The risk sits with the editor extension, and above all with Cursor users whose copy auto updated during that window. Cursor says it "will reach out directly" to affected users.

The disputed part: Open VSX or Cursor only?

Early reports, including StepSecurity's, said the bad build was first published to Open VSX (the open extension registry used by VSCodium, Windsurf and others) and reached Cursor through its mirror. OpenSourceMalware later added an update saying Cursor told them the origin was a compromise of the Claude Code listing in Cursor's own marketplace, "not Open-VSX." Cursor's notice describes only its own marketplace. Neither Anthropic nor the Eclipse Foundation, which runs Open VSX, had commented. If you run VSCodium, Windsurf or another editor that pulls from Open VSX and it updated on October 29, run the checks below anyway. They take seconds.

What the backdoor does

All three technical writeups agree on the behavior. A 66 line block was prepended to the extension's extension.js, so it runs the moment the editor loads the extension. You did not need to open a Claude chat. The rest of the bundle, including the bundled Claude Code binary, matched the normal release.

1. Recon. It collects hostname, username, OS and CPU type, home and working folders, your global Git email, your public IP, and the names (not the values) of up to 40 environment variables containing KEY, TOKEN, SECRET, PASS, AWS or GCP.
2. SSH key. It appends an Ed25519 public key with the comment svc-telemetry to ~/.ssh/authorized_keys.
3. SSH service. It tries to turn on the local SSH server: Remote Login on macOS, sshd on Linux, OpenSSH Server on Windows.
4. Reverse tunnel. It drops a private key named .stk_ plus 10 hex characters in your temp folder and loops an outbound SSH connection to 134.209.82.225 that forwards back to port 22 on your machine, retrying every 60 seconds.
5. Persistence. On macOS, a fake LaunchAgent called com.apple.sysmond. On Linux, an @reboot crontab line. On Windows, a scheduled task named SysMon with a Startup folder fallback (sysmon.cmd). The helper scripts live in ~/.config (.smt and .smtk, or smt.cmd and smtk on Windows).
6. Beacon. It posts the recon data over plain HTTP to port 8099 on the same server.

Two things limit the damage, and neither is a reason to skip cleanup. First, Cursor says it worked with the hosting provider to take the attacker server offline, so the tunnel and beacon no longer connect. Second, turning on SSH needs admin rights, which the extension does not have on most Macs and Windows PCs. Phorion found a bug that makes the macOS step skip itself for standard users, and Cursor says the step fails "outside of highly unusual circumstances." The key and the persistence still get written, and anyone who already had Remote Login or sshd running was reachable while the server was up. Phorion also flags a Linux bug that can wipe existing user cron jobs on repeat runs, so check your crontab even if you find nothing else.

How to check your machine

Cursor's official check looks for the key comment.

macOS and Linux:

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

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

Phorion points out that the malware decides whether to add its key by looking for the comment text, so a careful hunt also checks the fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. We recomputed that fingerprint from the published public key and it matches.

For a wider sweep on macOS or Linux, this read only script looks for the 2.1.313 folder in common extension directories, the key, the persistence files, the temp key, the cron line and a running tunnel. It changes nothing. We tested it against a scratch home folder with and without fake indicators.

#!/bin/sh
H="$HOME"; found=0
for d in "$H/.cursor/extensions" "$H/.vscode/extensions" "$H/.vscode-oss/extensions" "$H/.windsurf/extensions"; do
  ls -d "$d"/anthropic.claude-code-2.1.313* 2>/dev/null && found=1
done
grep -qs svc-telemetry "$H/.ssh/authorized_keys" && { echo "svc-telemetry key"; found=1; }
for f in "$H/.config/.smt" "$H/.config/.smtk" "$H/Library/LaunchAgents/com.apple.sysmond.plist"; do
  [ -e "$f" ] && { echo "persistence: $f"; found=1; }
done
ls "${TMPDIR:-/tmp}"/.stk_* 2>/dev/null && found=1
crontab -l 2>/dev/null | grep -q '\.config/\.smt' && { echo "cron entry"; found=1; }
pgrep -fl 'localhost:22' 2>/dev/null && found=1
[ "$found" = 1 ] && echo "INDICATORS FOUND" || echo "No indicators found"

A 2.1.313 folder with no other hits still means the code ran on load, so keep going with the cleanup steps. Teams should also search endpoint and network logs for connections to 134.209.82.225 on ports 22 and 8099; Cursor's notice lists the full set of hashes, file paths and command lines.

How to clean up an affected machine

1. Isolate first if this is a work machine, and tell your security team before deleting anything. Evidence matters for working out whether anyone actually logged in.
2. Run Cursor's remediation script: remediate-macos.sh as your normal user (not root) on a Mac, or remediate-windows.ps1 from an admin PowerShell on Windows. Both are linked from Cursor's notice. They remove the extension, the persistence, running tunnel processes and the key, and exit with an error if anything remains. On Linux, do it by hand: kill the ssh or autossh loop, delete the @reboot crontab line, ~/.config/.smt, ~/.config/.smtk and /tmp/.stk_*, then remove the svc-telemetry line from authorized_keys.
3. Check whether SSH got switched on (System Settings, Sharing, Remote Login on a Mac; systemctl status sshd on Linux; the OpenSSH Server service on Windows) and turn it off if you never used it.
4. Look for logins. Phorion notes that sessions arriving through the tunnel show up in SSH logs as coming from 127.0.0.1 or ::1. If you find one, rebuild the machine rather than clean it.
5. Reinstall the extension at 2.1.314 or later, or remove it if you mainly use the CLI.

What to rotate

Cursor's advice is to rotate "credentials and sessions accessible from affected hosts, from a trusted system." The beacon only sent variable names, but the planted key gave shell access wherever SSH was reachable, and from a shell everything in your home folder is readable. Rotate from a different, clean machine, in roughly this order:

• Git hosting: GitHub or GitLab tokens, SSH keys registered to your account, and any gh CLI login.
• Cloud: AWS, GCP and Azure keys, plus long lived session files in ~/.aws, ~/.config/gcloud and similar.
• AI providers: Anthropic, OpenAI and other API keys, and any gateway that stores them. Our LiteLLM incident guide has a fuller rotation checklist for gateway keys.
• CI, package registries and databases: npm and PyPI tokens, deploy keys, .env file secrets.
• Your own SSH private keys in ~/.ssh, since the attacker could have copied them.

How to make the next poisoned extension less dangerous

This is the second agent tooling supply chain incident in ten days, after LiteLLM 1.107.0 on October 21. Coding agents run with your full user rights, which makes their extensions a rich target. A few habits cut the blast radius:

• Turn off automatic extension updates for high value extensions, or for all of them, and update after a release has been public for a day. In VS Code style editors the setting is extensions.autoUpdate. That delay alone would have kept most people off 2.1.313, which was pulled within about 11 hours.
• Compare versions across registries. A version that exists in one marketplace but not in the vendor changelog or the other registries is a warning sign. Claude Code's changelog never listed 2.1.313.
• Prefer the CLI where it fits. Claude Code's terminal version comes straight from Anthropic's installer or npm and does not depend on a third party marketplace. See our Claude Code vs Codex vs Gemini CLI comparison for how the terminal tools differ.
• Keep SSH off on laptops that do not need it, and audit authorized_keys now and then. An empty or missing file is the safest state for most developer machines.
• Keep secrets out of plain environment variables where you can; a secret manager or short lived tokens limit what a recon step can find.
• Run long agent jobs in a sandbox. Background and cloud sessions are a good fit for isolated environments; our guides to Claude Code background agents and E2B vs Daytona vs Modal cover the options.

If this pushes you to rethink your editor setup altogether, our roundup of the best AI coding assistants compares Cursor, Cline, GitHub Copilot and Claude Code side by side.

FAQ

Is the Claude Code CLI affected?

No evidence says so. OpenSourceMalware states the @anthropic-ai/claude-code npm package is not malicious, and the npm registry never listed a 2.1.313 release. It went from 2.1.312 on October 27 to 2.1.314 on the evening of October 29.

I use VS Code with the Microsoft Marketplace. Should I worry?

The reports describe the Microsoft Marketplace copy as clean, and its download endpoint now returns 404 for 2.1.313. Running the one line svc-telemetry check costs nothing, so do it if your extension updated on October 29.

Is updating to Claude Code 2.1.314 enough?

No. The malware writes standalone scripts and a LaunchAgent, cron line or scheduled task that keep running after the extension is replaced. Run the checks and the cleanup steps first, then update.

Did the attacker get my API keys?

The beacon sent only the names of matching environment variables, not their values. But on any machine where SSH was reachable, the planted key allowed a full login while the attacker server was up, so rotate secrets if you find any indicator.

Was Anthropic hacked?

Not established. Cursor says the build "was not developed by Anthropic," and how it reached the marketplace has not been explained publicly. Anthropic had not commented when we checked on the morning of October 30.