DEV Community

Cover image for Claude Code Extension Backdoor in Cursor: Uninstalling Won't Remove the SSH Key
Alan West
Alan West

Posted on Originally published at blog.authon.dev

Claude Code Extension Backdoor in Cursor: Uninstalling Won't Remove the SSH Key

#vscode #security #ai #productivity

If you run Cursor on macOS or Windows and it pulled the Claude Code extension (anthropic.claude-code) 2.1.312 or 2.1.313 on October 29, your machine may now have a stranger's SSH key in ~/.ssh/authorized_keys and a reverse SSH tunnel that restarts at login. Uninstalling the Claude Code extension doesn't remove it. Updating to 2.1.314 doesn't remove it either.

The check takes about 5 minutes and uses the indicators Cursor, Phorion and Microsoft published. After that I cover what to rotate and how to stop your editor from installing whatever turns up in a marketplace overnight.

What happened with the Claude Code extension backdoor in Cursor

According to Cursor's security notice, tampered builds of Anthropic.claude-code versions 2.1.312 and 2.1.313 for Windows and macOS were served from the Cursor Extension Marketplace between about 2:27am and 1:35pm PT on October 29, 2026. Cursor says those builds "were not developed by Anthropic". StepSecurity reports that, by Cursor's count, "at most 5,000" of its users received the trojanized build.

Phorion published a teardown. Someone had prepended code to the minified extension.js, and it runs as soon as Node loads the file, before activate is even called. You didn't have to click anything or open a Claude panel; loading the extension was enough.

The part that bothers me most is the listing itself. It used the real extension ID, the one you'd tell a junior dev is safe to trust. Most of us have learned to look out for typosquats like anthropic-official-claude, and that habit was no help here.

Who is affected (and who isn't)

The early headlines went too far. DoublePulsar ran "Anthropic hacked to deliver remote access trojan", but Anthropic engineers said on Hacker News that their systems and laptops weren't compromised. They also made sure their next real update was 2.1.314, "in order to disambiguate" it from the tampered builds. Per StepSecurity and Microsoft:

Where you got the extension 2.1.312 2.1.313
Cursor Marketplace (Win/macOS) malicious build served Oct 29 malicious
Open VSX (VSCodium, Windsurf, etc.) clean not found
Microsoft VS Code Marketplace not affected never published

So plain VS Code and VSCodium users can relax, mostly. Cursor users on macOS or Windows who had the editor running that day should check. The implant also contains Linux persistence logic, so Linux Cursor users should run the checks too. They take about a minute.

I don't fully buy Anthropic's "not our systems" line as the end of the story, though. The extension said "Anthropic" on it. As one HN commenter put it, "the malware has their branding and their name on it." Cursor's own docs say extension searches and downloads go through its proxy at marketplace.cursorapi.com, and Anthropic's Felix Rieseberg wrote on HN that a malicious actor "used access to Cursor's marketplace" to ship the build under the real ID. Cursor's notice says it audited access and rotated keys, but not how the attacker got in. Until someone explains that, I think both companies own part of this.

Step 1: list your extensions and versions 

cursor --list-extensions --show-versions | grep -i claude
code   --list-extensions --show-versions | grep -i claude
codium --list-extensions --show-versions | grep -i claude
Enter fullscreen mode Exit fullscreen mode

A clean result here doesn't settle anything. If Cursor has already updated you to 2.1.314, the 2.1.313 folder is probably gone, but the persistence it dropped outside the extension folder is still there. Look on disk too:

ls -d ~/.cursor/extensions/anthropic.claude-code-* 2>/dev/null
find ~/.cursor/extensions -path '*claude-code*' -name extension.js \
  -exec shasum -a 256 {} \;
Enter fullscreen mode Exit fullscreen mode

The backdoored extension.js hashes to ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15. Cursor's notice also lists VSIX hashes for each version and platform.

Step 2: check for the SSH key and persistence (macOS / Linux)

If you only run one set of checks, run these:

# 1. The planted login key
grep -n 'svc-telemetry' ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys | grep '0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk'

# 2. Dropped scripts and keys
ls -la ~/.config/.smt ~/.config/.smtk 2>/dev/null
ls -la /tmp/.stk_* "$TMPDIR"/.stk_* 2>/dev/null

# 3. macOS LaunchAgent pretending to be Apple
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null
launchctl list | grep sysmond

# 4. Linux cron entry
crontab -l 2>/dev/null | grep '\.smt'

# 5. Live tunnel
ps -eo pid,args | grep -E '134\.209\.82\.225|:0:localhost:22' | grep -v grep
Enter fullscreen mode Exit fullscreen mode

Run the fingerprint check even if the grep finds nothing. Phorion points out that the malware looks for the string svc-telemetry and not the key itself, so a key with an edited comment would slip past a plain grep.

Step 2 (Windows) 

Select-String -Path "$HOME\.ssh\authorized_keys","C:\ProgramData\ssh\administrators_authorized_keys" -Pattern 'svc-telemetry' -ErrorAction SilentlyContinue
Get-ScheduledTask -TaskName SysMon -ErrorAction SilentlyContinue
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Test-Path "$env:USERPROFILE\.config\smt.cmd"
Get-ChildItem $env:TEMP -Filter '.stk_*' -Force
Enter fullscreen mode Exit fullscreen mode

Network indicators

If you have firewall, DNS or EDR logs, search them for:

  • 134.209.82.225 on TCP 22 (reverse SSH as user tunnel, with -R *:0:localhost:22)
  • http://134.209.82.225:8099/beacon (HTTP POST)
  • SSH logins from 127.0.0.1 or ::1 using the svc-telemetry key. The operator comes back in through the tunnel, so the login looks local.

Microsoft's post includes Defender XDR hunting queries if your company runs that.

How bad is it if you find something?

The payload isn't very good, which is lucky. Phorion found that on macOS it runs systemsetup -getremotelogin without admin rights, gets an error, and so never turns Remote Login on. On Windows the OpenSSH install goes through a helper hardcoded to /bin/sh, which probably fails. Cursor says the attacker's server is now offline.

That said, if Remote Login was already enabled on your Mac, or sshd was already running on your Linux box, the tunnel pointed straight at it and the attacker had a working SSH path into your account for as long as it stayed up.

The beacon also sent your hostname, username, git email, public IP, and up to 40 environment variable names matching KEY|TOKEN|SECRET|PASS|AWS|GCP. Only the names went out, not the values, but that still gives the attacker a list of which machines hold AWS keys and which ones are worth logging into.

Clean up, then rotate

Cursor provides remediate-macos.sh (run as your user, not root) and remediate-windows.ps1 (run as Administrator) on the notice page. If you'd rather do it by hand:

  1. Kill the ssh/autossh processes and their retry loop.
  2. Unload and delete com.apple.sysmond.plist, remove the @reboot cron line, or delete the SysMon task and sysmon.cmd. Then delete ~/.config/.smt and .smtk.
  3. Remove only the svc-telemetry line from authorized_keys, and delete the .stk_* files.
  4. Check that Remote Login / sshd is in the state you expect.

Phorion warns that a bug in the malware's cron check can wipe your existing user cron jobs on repeat runs, so compare crontab -l against what you remember having.

If you found any artifact, rotate everything that user account could reach. Start with anything an env var name like AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN pointed to, then:

  • your SSH keys (generate new ones and remove the old public keys from GitHub, GitLab and your servers)
  • git tokens, gh auth sessions, and npm/PyPI publish tokens
  • cloud credentials in ~/.aws, ~/.config/gcloud and ~/.azure
  • Anthropic, OpenAI and other API keys sitting in .env files

Do the rotation from a different machine. If you're a company with EDR, Microsoft and Cursor both suggest isolating the host and considering a rebuild. I'd rebuild any machine where you can't rule out an inbound login.

Pin extensions and stop auto-updating them

Auto-update is how a build like this reaches thousands of laptops without anyone clicking anything, and it's easy to switch off.

In VS Code, VSCodium or Cursor settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}
Enter fullscreen mode Exit fullscreen mode

Cursor also has an install cooldown. Per Cursor's extensions docs, the per-user setting is extensions.installCooldownHours, and team admins can enforce "Marketplace Install Cooldown (hours)" fleet-wide under Team settings → Security & automation. The same page has an "Allowed extensions" list and "Require Extension Signature Verification". The team default is 0, meaning off. I'd set it to 72. An 11-hour exposure window means even a one-day delay would have skipped this entirely.

To pin a known-good version explicitly:

cursor --install-extension anthropic.claude-code@2.1.314
Enter fullscreen mode Exit fullscreen mode

Yes, you'll lag a few days behind on features, and that's fine with me.

So, do you let your editor auto-update extensions, or did this just change your mind? And who do you think owns this one, Cursor for running the marketplace or Anthropic for the name on the box? Tell me in the comments.

Sources

Top comments (0)