Skip to content
AI Coding

Claude Code Backdoor on Cursor: Check & Fix Guide

Backdoor in Claude Code for VS Code extension on the Cursor Marketplace hit ~5k users. Here's the exact check, cleanup scripts, and what uninstall misses.

5 min readBeginner

Your editor just updated. Did it also plant an SSH key?

Routine Cursor auto-update. Morning of October 29, 2026. Claude Code for VS Code on the Cursor Marketplace – version 2.1.313 – loaded a backdoor the instant the extension host started. No chat. No click. Just an SSH foothold attempt.

At most 5,000 users, per Cursor, across roughly 2:27am-1:35pm PT. Build wasn’t Anthropic’s. Attacker C2 is dead now. None of that proves your box is clean if you updated that day.

Do this in order: one-line check, proper cleanup, then smaller blast radius next time a marketplace ship goes wrong.

Why “just update” or uninstall falls short

Most people open Extensions, see 2.1.314+, hit Update, and walk away. That blocks the bad bundle from loading again. It does not undo what already executed.

The catch is persistence outside the extension. Cursor’s security notice is blunt: uninstall may not be enough. The loader wrote an attacker Ed25519 key tagged svc-telemetry, dropped standalone hooks (LaunchAgent on macOS, scheduled task/Startup on Windows, cron-style on Linux), and could keep retrying a reverse tunnel. Those keep running after the VSIX is gone.

Turns out the local SSH enable step usually needs admin and often failed on normal macOS/Windows hosts – yet the key, files, and beacon still landed. Community teardown on OpenSourceMalware matches Cursor: a short IIFE prepended to real extension.js. Claude UI still answers. Nothing looks broken.

Check whether it touched you

Key check first. Comment present → treat the machine as impacted, full tunnel or not.

macOS / Linux:

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 glance:

  • Cursor → Extensions → Claude Code → 2.1.314 or newer.
  • Folder: ~/.cursor/extensions (or equivalent) for any anthropic.claude-code-2.1.313-* directory.

Deeper signals if you want them: ~/Library/LaunchAgents/com.apple.sysmond.plist. ~/.config/.smt / .smtk. Windows task SysMon or Startup sysmon.cmd. Long-lived ssh/autossh with -R *:0:localhost:22. Old traffic to 134.209.82.225:8099 (dead). Bad key fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. Malicious VSIX SHA-256 samples Cursor published: darwin-arm64 432ccdee3801f99e52b8fe31f69ea9870118e96ea7ef9ecabed1479621b5ab62; win32-x64 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081.

Clean it the way Cursor intends

Positive key check? Isolate a work machine that holds secrets. Then run the official remediators – they strip bad extension folders, persistence, tunnel processes, and the key, and exit non-zero if junk remains.

  1. Grab remediate-macos.sh or remediate-windows.ps1 from Cursor’s security notice (linked above).
  2. macOS: affected user, not root – bash remediate-macos.sh.
  3. Windows: elevated PowerShell – powershell -ExecutionPolicy Bypass -File .remediate-windows.ps1.
  4. Linux: no official script as of that notice. Manually delete the svc-telemetry line, kill tunnel processes, remove ~/.config/.smt* plus any infected extension dir, drop @reboot crontab lines that call those scripts, reinstall ≥2.1.314.
  5. From a clean machine, rotate anything reachable from the affected account – Git tokens, cloud keys, SSH keys, editor logins. The loader beaconed env names matching KEY/TOKEN/SECRET/PASS/AWS/GCP plus Git email and public IP. Names only. A working tunnel on a host that already had SSH open is the path that could have gone further.

After the script: re-run grep/Select-String and ls the persistence paths. Clean script exit + second negative key check is the minimum before you trust the box.

Then pull Claude Code 2.1.314+ from the restored marketplace. Registry timelines show 2.1.313 missing from the normal Open VSX / VS Marketplace / npm sequence (2.1.312 → 2.1.314); clean 2.1.314 is what you want pinned.

What a real auto-update day looked like

Solo dev. Cursor left open overnight. Auto-update pulled 2.1.313 mid-morning. Never opened a Claude panel. Extension host still ran the loader, appended the key, wrote LaunchAgent (or SysMon), POSTed host metadata. Afternoon: Claude still answers. The only tells are one comment line in authorized_keys and a plist/task you didn’t create.

If Remote Login / sshd was already on, the “admin failed” path protected less than you hoped. If it wasn’t, the key and persistence still sat waiting. Weird quiet, right? That’s the point of the one-liner – not another IOC essay.

Hardening so the next marketplace incident is smaller

Marketplace trust is convenient. It’s also one bad VSIX away from code execution in your extension host. How small can you make the next mistake without slowing every commit?

  • Blind auto-update off for high-privilege extensions when workflow allows – pin versions; skim changelogs before accepting.
  • Extension host = code execution. Prefer official registries when you can; this distribution path was Cursor’s own marketplace.
  • After any surprise extension bump: grep unexpected comments in authorized_keys; skim LaunchAgents / scheduled tasks.
  • Secrets out of long-lived shell env where practical. Short-lived tokens and hardware-backed keys limit what a beacon of names helps an attacker target later.

Worth wiring next: how your Cursor build resolves extensions versus stock VS Code forks, and basic authorized_keys comment hygiene on every laptop you ship from.

FAQ

Was Anthropic’s own release or the Microsoft Marketplace hit?

No. Malicious 2.1.313 wasn’t from Anthropic. Confirmed path: Cursor marketplace. Other registries jump 2.1.312 → 2.1.314.

I already updated to 2.1.314 – am I done?

Only if you never ran 2.1.313 and the key check is clean. Updated yesterday after a possible morning install? Run the grep/PowerShell line. Hit → official remediate script, then rotate credentials from another machine. Miss → you’re done.

Could the attacker still be in if the C2 is dead?

Live reverse tunnel and :8099 beacon are gone – Cursor had the hoster pull 134.209.82.225. Dead C2 ≠ clean disk. Leftover key + persistence is still a foothold for anyone who can use that authorized_keys entry later. Strip artifacts. On high-value hosts, rebuild beats trusting a partial cleanup you half-remember from a busy afternoon.

Next: terminal, one-line svc-telemetry check for your OS. Hit message → Cursor’s remediation script before the next push.

Related Tutorials