A Trojanized Claude Code Extension Hit Up to 5,000 Cursor Users: What Happened and a 15-Minute Check for Your Team

On October 29, 2026, a tampered build of Anthropic's Claude Code extension, version 2.1.313, was served to developers through the Cursor extension marketplace for about eleven hours. It looked like the real thing because, apart from one small block of code, it was the real thing. That block tried to plant an SSH backdoor on the developer's machine.

I run a small dev agency, and our team lives in VS Code-style editors with AI extensions installed. So this morning (October 30, PKT) we went through our own machines. This post is what we learned: what is confirmed, what isn't, how to check your machines in about 15 minutes, and the habits I think every team should change because of it.

My short version: your editor's extension list is part of your supply chain, and it auto-updates with your laptop's full permissions. Most teams review npm dependencies and never look at their extensions.

What we actually know (as of Oct 30)

Everything below comes from Cursor's security notice and two independent malware analyses (StepSecurity and OpenSourceMalware). Where they differ, I say so.

• The bad version: anthropic.claude-code version 2.1.313. Cursor says this version "was not developed by Anthropic."
• The window: Cursor says it was available in its marketplace between about 2:27am and 1:35pm PT on October 29 (09:27 to 20:35 UTC).
• The reach: Cursor says at most 5,000 users were affected and that it will contact them directly.
• What Cursor did: removed the version, then shut down its whole extension marketplace "out of an abundance of caution," audited access, says it found no other tampered extensions, rotated its keys, rebuilt the marketplace and brought it back. It also worked with the hosting provider to take the attacker's server offline.
• The fix: StepSecurity reports a clean 2.1.314 was published on October 30 (01:07 UTC), and that it verified both 2.1.312 and 2.1.314 are free of the indicators.

What is still unclear

• How the build got published. StepSecurity says it appeared on the Open VSX registry under the legitimate Anthropic publisher namespace, and that Cursor's marketplace mirrors that registry. It also says how the version got in, "whether through compromised publisher credentials or another mechanism, has not been publicly established."
• Open VSX itself. The two analyses disagree here. StepSecurity says the version was distributed through Open VSX. OpenSourceMalware's write-up lists the Open VSX extension as not malicious. Some news coverage describes it as a compromise of the Cursor marketplace. I'd treat "where exactly it entered" as unconfirmed until there's an official root-cause report.
• The npm CLI is not part of this. OpenSourceMalware says the @anthropic-ai/claude-code npm package is not malicious, and Cursor says it has no evidence that other versions or the official distribution were affected.

Headlines saying "Anthropic was hacked" go further than the evidence. What's confirmed is that a malicious build carried Anthropic's extension name.

What the malicious code did

This is the part worth understanding even if you never installed Claude Code, because the technique is generic.

It ran on load. StepSecurity found the malicious extension.js was about 7 KB larger than the clean release, with a self-contained loader placed in front of the normal bundle. OpenSourceMalware describes it as a 66-line block inserted before the legitimate code. The extension had no install or postinstall scripts. You didn't have to open a Claude chat; the editor loading the extension was enough.

It collected host details. Per Cursor: hostname, username, OS, architecture, home directory, the names of environment variables, working directories, your configured Git email and your public IP. StepSecurity notes the env var names collected matched patterns like KEY, TOKEN, SECRET, PASS, AWS and GCP. Names, not values, but that still tells an attacker which credentials are sitting on the machine.

It planted an SSH key. It appended an attacker key labelled svc-telemetry to ~/.ssh/authorized_keys. The label is chosen to look boring.

It tried to open a reverse SSH tunnel. It tried to enable the local SSH server and connect out to the attacker's host, exposing your port 22 through the tunnel. Cursor says that on most macOS and Windows machines this step fails, because turning on the SSH service needs admin rights the extension normally doesn't have, and because of errors in the malicious code. The exception is an editor started with administrator privileges.

It made itself persistent. A LaunchAgent on macOS named com.apple.sysmond, a scheduled task named SysMon (with a Startup-folder fallback) on Windows, and, per StepSecurity, a cron @reboot entry on Linux. Background scripts retry the tunnel about every 60 seconds.

It phoned home over plain HTTP with a POST to /beacon on port 8099.

The important detail for cleanup: uninstalling the extension isn't enough. Cursor and StepSecurity both say the payload drops standalone scripts that keep running after the extension is gone.

The 15-minute check we ran

If anyone on your team uses Cursor, or any editor that pulls from Open VSX, and had the Claude Code extension installed on October 29, do this today. These checks are read-only.

1. Look for the planted key. This is the check Cursor recommends.

macOS and Linux:

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

Windows (PowerShell), from Cursor's notice:

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

2. Check whether the bad version is on disk. StepSecurity suggests grepping installed extension bundles for the attacker IP or the key label. On macOS and Linux, a quick sweep of the usual extension folders looks like this:

for d in ~/.cursor/extensions ~/.vscode/extensions ~/.vscode-oss/extensions; do
  [ -d "$d" ] && ls -d "$d"/anthropic.claude-code-2.1.313* 2>/dev/null
  [ -d "$d" ] && grep -rls --include=extension.js -e svc-telemetry -e '134.209.82.225' "$d" 2>/dev/null
done

No output is good. Adjust the folder list for whatever editors your team uses.

3. Look for persistence, using the file names Cursor published:

• macOS: ~/Library/LaunchAgents/com.apple.sysmond.plist, ~/.config/.smt, ~/.config/.smtk, and $TMPDIR/.stk_* files
• Windows: scheduled task SysMon, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd, %USERPROFILE%\.config\smt.cmd and smtk
• Linux (per StepSecurity): an @reboot line in crontab -l

# macOS / Linux quick look
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk 2>/dev/null
crontab -l 2>/dev/null | grep -n '@reboot'
pgrep -fl 'ssh -N -R|autossh' 

4. If you have network logs, search for connections to 134.209.82.225 (SSH on 22, HTTP on 8099). Cursor notes that lookups to ifconfig.me or api.ipify.org are normal services and not a sign of compromise by themselves.

If you find something

Follow Cursor's order, and don't improvise:

1. Isolate the machine.
2. Collect evidence before you delete anything.
3. Run Cursor's published remediation script for your OS (remediate-macos.sh as the affected user, or remediate-windows.ps1 as Administrator), which removes the extension, persistence, tunnel processes and the key, and exits non-zero if anything remains.
4. Rotate everything that machine could reach, from a different, clean machine: GitHub/GitLab tokens, CI secrets, cloud keys, SSH keys, package registry tokens. Remember that the beacon told the attacker which credential names existed.
5. If there's any sign the tunnel actually connected, rebuild the machine rather than cleaning it. StepSecurity gives the same advice.

Then update to 2.1.314 or later.

Five lessons for teams

1. Extensions are dependencies. Inventory them.

We have lockfiles for npm and pip. We have nothing for editor extensions, yet they run with the same user permissions and can read the same ~/.ssh, ~/.aws and .env files. The first thing we did after this was write down which extensions each person has installed (code --list-extensions --show-versions works for VS Code; check your editor's equivalent). Being able to answer "who had 2.1.313?" in five minutes instead of an afternoon is half of incident response.

2. Auto-update is a trust decision, not a default

The trojanized build reached people because updates are automatic. I'm not going to tell you to turn updates off everywhere, since stale extensions carry their own risk. But for a team, a short delay helps: let a new version sit for a day or two before it lands on machines that touch production. This one was pulled within about eleven hours. Where your editor allows it, turn off extension auto-update on admin machines and update on purpose.

3. The publisher name is not a signature

This build appeared under the real publisher name, not a typosquat, according to StepSecurity. "It's from Anthropic, it's fine" was exactly the assumption being exploited. What actually protects you is how fast your tooling notices that a specific version has been flagged.

4. Don't run your editor as admin

Cursor's notice says the tunnel step failed on most machines because the extension didn't have admin rights. That's the simplest lesson in this whole incident. Running an IDE elevated "to fix a permissions error" turns a failed attack into a working one.

5. Laptops are production now

This is the second time this week I've written this. The Binance incident's preliminary cause was a compromised engineer's laptop, and now an AI coding extension tried to open SSH on developer machines. If a laptop can reach production with long-lived credentials, then the laptop is production. Short-lived SSO-backed tokens, no plaintext cloud keys on disk, and a separate profile or machine for production access all limit what any one bad extension can steal.

A note on AI coding tools specifically

AI extensions are attractive targets. They're installed by a huge number of developers, they update often, and users expect them to do powerful things like run commands, read files and touch Git. A malicious version doing something odd is harder to spot when the legitimate version already does a lot.

That isn't a reason to stop using them. We use them every day. It's a reason to treat them like any other privileged software: know what's installed, know what version, keep secrets out of plaintext files they can read, and have a plan for the day one of them is pulled.

Sources

The primary source is Cursor's security notice for Anthropic.claude-code 2.1.313, which has the full indicator list, file hashes and remediation scripts. The technical detail on the loader and the registry timeline comes from StepSecurity's and OpenSourceMalware's published analyses. How the build was published is not yet confirmed, and I'll update this post if an official root cause comes out.

Did anyone on your team have 2.1.313 installed, and does your company keep any list of which editor extensions people run?