Skip to content

Claude Code Extension Backdoor: How to Check Fast

Backdoors in official Claude Code extensions hit Cursor users via v2.1.313. Here's the 2-minute check, cleanup steps, and what still stays after uninstall.

5 min readBeginner

Did you install or auto-update Claude Code inside Cursor on October 29 and now wonder if a backdoor is sitting on your laptop? That question is the whole job today.

Here’s the practical path for backdoors in official Claude Code extensions: which build mattered, a two-minute yes/no, cleanup that goes past uninstall, then rotate and harden. Trusted publisher name. Bad VSIX. About eleven hours live.

What actually shipped (and what didn’t)

Marketplace users could pull Anthropic.claude-code 2.1.313 from roughly 2:27am-1:35pm PT on October 29, 2026 – about eleven hours – according to Cursor’s security notice. Cursor estimates at most 5,000 affected users, says it will reach out directly, and states the build was not developed by Anthropic.

Loader ran on extension module load. Editor startup. Webview open. No Claude chat required. Before the real extension code, it tried host recon (hostname, user, OS/arch, home, git email, names of env vars matching KEY/TOKEN/SECRET/PASS/AWS/GCP – values not in the first beacon per the analyses), appended an Ed25519 key commented svc-telemetry into authorized_keys, aimed a reverse tunnel at 134.209.82.225 plus a POST to :8099/beacon, and dropped persistence. C2 is offline now; Cursor worked with the hoster.

Clean line: 2.1.314. Turns out the live malicious serve was Cursor’s own marketplace path. OpenSourceMalware later listed npm @anthropic-ai/claude-code, the Open VSX listing, and Microsoft Marketplace builds as not the malicious artifact they examined (registry checks around October 30).

Two-minute check: were you hit?

Skip the timeline threads. Use the indicator from the notice.

macOS / Linux – key comment:

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

Windows (PowerShell):

$files = "$HOME.sshauthorized_keys", "C:ProgramDatasshadministrators_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" }

Version + leftover folder:

cursor --list-extensions --show-versions | grep -i claude-code
# or: code --list-extensions --show-versions | grep -i claude-code
ls ~/.cursor/extensions 2>/dev/null | grep -i claude-code
# Windows: dir $HOME.cursorextensions | findstr claude-code

Bad public key fingerprint (Cursor): SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. svc-telemetry match means impacted – even if Claude still answers prompts.

Pro tip: Check the key before mass-deleting extension folders. The key is the cleanest signal the loader actually ran. Wipe first and you lose the easiest yes/no.

Cleanup that goes past uninstall

Removing anthropic.claude-code is not enough. Standalone persistence, the authorized key, and tunnel retry logic can remain after the extension is gone – Cursor is explicit about that.

Official path (as of the notice):

  1. Isolate if you see the key or known files.
  2. Run Cursor’s remediations from the notice – macOS: bash remediate-macos.sh as the affected user (not root); Windows: elevated PowerShell, remediate-windows.ps1 with ExecutionPolicy Bypass.
  3. Verify leftovers yourself if you want belt-and-suspenders.

Quick artifact sweep

Platform Look for
macOS ~/Library/LaunchAgents/com.apple.sysmond.plist, ~/.config/.smt, ~/.config/.smtk, $TMPDIR/.stk_*
Windows Task SysMon, %USERPROFILE%.configsmt.cmd, Startup sysmon.cmd, %TEMP%.stk_*
Linux (community IOCs) ~/.config/.smt / .smtk, odd @reboot crontab lines, reverse ssh/autossh with -R toward localhost:22

Then move to 2.1.314 (or current clean) from a channel you trust. Rotate anything that machine could reach – API keys, cloud CLIs, git tokens, SSH keys – from a different, clean system. Env-var names went out in recon; values may have stayed out of the first beacon. Interactive access later would change that picture fast.

Advanced: why “SSH failed” still isn’t a free pass

The catch: enabling local SSH usually needs admin rights the extension lacks on most macOS and Windows hosts. Enable step fails. Tunnel login often never works. Damage limited – not zero. The planted key, persistence files, and host beacon still land.

Ever launch Cursor elevated? On Linux, user-level service tricks behave differently. Assume the worse path until you prove otherwise. While cleaning, still hunt long-lived ssh -N -R '*:0:localhost:22' / autossh.

Same extension ID, different bits: Cursor’s store vs Open VSX vs Microsoft Marketplace. Publisher string alone did not protect anyone here. Early noise pointed at other registries; the confirmed live malicious window was Cursor’s marketplace, with npm / Open VSX / Microsoft reported clean for 2.1.313 after the October 30 updates.

Honest limits of what we know

How the bad build entered the publish path – credential theft, token leak, something else – is not publicly established. Notices say so. Don’t invent a root cause on the IR ticket.

Host held production secrets? Rebuild is the safest move. Scripted cleanup clears known artifacts; it cannot promise no follow-on if a tunnel ever worked. Blocking 134.209.82.225 on ports 22 and 8099 is still worth doing – Cursor already says that server is offline.

Supply-chain trust used to mean “big publisher name on the marketplace tile.” After a window this short, that heuristic feels thin. What would you want your laptop to prove before it holds cloud keys again?

FAQ

I only use VS Code from Microsoft’s Marketplace – am I clear?

For this incident, yes on that channel: Microsoft Marketplace and npm were reported not malicious. Still run the svc-telemetry grep if the same machine ever touched Cursor or a mirrored install.

Uninstall fixed it, right?

No. Run remediate (or manually clear the key, LaunchAgent/task/Startup entries, and .smt-style paths), then rotate secrets from a clean box. Landing on 2.1.314 alone does not prove the disk is clean.

Should every team ban auto-updates for AI extensions now?

Auto-update is how many hosts ate 2.1.313 inside an 11-hour window. Pinning via allow-lists – VS Code extensions.allowed / enterprise AllowedExtensions-style controls where your editor supports them – is a real control. Know which registry each fork actually pulls from. Banning every AI extension forever is a business call. Treating dev laptops like privileged endpoints and alerting on new authorized_keys lines plus mystery LaunchAgents is the part that still works after this incident fades.

Next: run the svc-telemetry one-liner on every machine that had Cursor + Claude Code last week. “Key found” → isolate, remediate for your OS, rotate from a clean host, then 2.1.314. Check before you close the tab.