Was Your Cursor Install Backdoored? How to Check for the Claude Code 2.1.313 Extension

Last night I wrote a cheerful little post about SSHing into your servers when the agents go down. This morning I found out that, on the same day, a fake Claude Code extension in Cursor's marketplace was trying to add someone else's key to people's authorized_keys file. Great timing on my part.

Here's what happened, in plain terms. On October 29, Cursor's VS Code extension marketplace served a tampered build of the Claude Code extension, version 2.1.313. Cursor says it wasn't built by Anthropic and that at most 5,000 users were affected. If your editor picked it up, it tried to plant an SSH backdoor and set up startup items so the backdoor would come back after a reboot.

Odds are you weren't hit. Cursor puts it at 5,000 users at most. But the check takes about a minute, and if you were hit, uninstalling the extension isn't enough. So let's go through it.

According to Cursor's security notice, a modified version of Anthropic's Claude Code extension was available in the Cursor marketplace from about 4:27 AM to 3:35 PM CDT on October 29. The bad code runs as soon as the editor loads the extension. OpenSourceMalware found a 66-line loader added to the top of the extension's main JavaScript file, so you didn't have to open Claude or ask it anything.

Per Cursor, the payload:

• Collected host details: hostname, username, OS, home folder, working directories, your Git email, your public IP and the names (not values) of your environment variables.
• Added an attacker's SSH key, labeled svc-telemetry, to authorized_keys.
• Tried to turn on the machine's SSH service and open a reverse SSH tunnel to the attacker's server.
• Set up persistence: a LaunchAgent on macOS, or a scheduled task with a Startup-folder fallback on Windows. Background scripts retry the tunnel about every 60 seconds.
• Reported back to the attacker over plain HTTP on port 8099.

Now the good news, also from Cursor. Turning on SSH needs admin rights, which the extension doesn't have on most Macs and Windows PCs, so on most machines the tunnel step failed and the attacker couldn't log in through it. Cursor also worked with the hosting provider to take the attacker's server offline. Still, the key, the persistence and the host report all happen without admin rights, so Cursor says to clean up regardless.

Cursor pulled the version, shut its whole extension marketplace down as a precaution, audited it, says no other extensions were tampered with, rotated its own keys, rebuilt the marketplace and brought it back. It says it will contact affected users directly, so keep an eye on your inbox too.

One wrinkle, now mostly settled: early reports said the bad build came from Open VSX, the open extension registry, and StepSecurity still describes it that way. Anthropic says otherwise. On the morning of October 30, Anthropic's Felix Rieseberg said this wasn't a compromise of Anthropic's systems or employee laptops. Someone used access to Cursor's marketplace to publish a tampered copy that Anthropic didn't build or publish, and Anthropic's official channels aren't affected. Another Anthropic engineer added on Hacker News that 2.1.313 was never published on Open VSX, the VS Code Marketplace or any of Anthropic's official hosts, and that Anthropic numbered its next update 2.1.314 so the two couldn't be confused. OpenSourceMalware's updated write-up agrees, and Brandefense and Rescana both found the public registries jump from 2.1.312 to 2.1.314. So I'm going with Cursor's and Anthropic's account: the bad build came through Cursor's marketplace.

Side note: in last night's post I mentioned a "Service Degradation with VS Code Extensions" incident on Cursor's status page, posted at 4:38 PM CDT. That's about an hour after Cursor says it pulled the bad version. The status page didn't say why, so all I'll say is that the timing lines up.

Open the Extensions panel in Cursor and look at Claude Code's version. Or list it from a terminal:

ls ~/.cursor/extensions | grep -i claude-code

On Windows, in PowerShell:

Get-ChildItem "$HOME\.cursor\extensions" -Filter "anthropic.claude-code-*"

Seeing 2.1.314 now doesn't clear you. The extension may have auto-updated past 2.1.313 after it ran. If you had Claude Code installed in Cursor at all during that window, do the next two checks. They're fast.

If the folder is still there, you can check the file itself. Cursor says the tampered extension.js contains the attacker's IP and the key label:

grep -l -E '134\.209\.82\.225|svc-telemetry' ~/.cursor/extensions/anthropic.claude-code-*/extension.js

Cursor published hashes for the Apple Silicon Mac build (darwin-arm64) and the 64-bit Windows build (win32-x64). Its notice doesn't mention other builds. On Linux or anything else, the key check below still takes five seconds.

These are Cursor's own checks. On macOS (the same line works on Linux):

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

On Windows, in PowerShell. This also checks the admin keys file that Windows' OpenSSH server uses:

$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; machine not impacted" }

If it says the key was found, the machine is affected. While you're in there, look at every key in the file, not just this one. ssh-keygen -lf ~/.ssh/authorized_keys lists each key's fingerprint and comment. The attacker's key fingerprint is SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. Any key you can't explain deserves a closer look.

This is why uninstalling isn't enough. These are the exact files and startup items Cursor lists. On macOS:

ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk 2>/dev/null
launchctl list | grep -i sysmond
ls -la "$TMPDIR"/.stk_* /tmp/.stk_* 2>/dev/null
pgrep -fl "\.stk_|\.config/\.smt"

That LaunchAgent is named com.apple.sysmond to look like part of macOS. It isn't. It sits in your user LaunchAgents folder.

On Windows, in PowerShell:

Get-ScheduledTask -TaskName SysMon -ErrorAction SilentlyContinue
Test-Path "$HOME\.config\smt.cmd", "$HOME\.config\smtk"
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Get-ChildItem $env:TEMP -Force -Filter ".stk_*"
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match '\.stk_|\.config\\smt' } | Select-Object ProcessId, CommandLine

StepSecurity also lists a cron @reboot entry as a persistence method. Cursor's notice doesn't mention cron, but crontab -l on a Mac or Linux box costs nothing.

Tunnel processes show up as ssh -N -R or autossh -M 0 with StrictHostKeyChecking=no. Connections to 134.209.82.225 on port 22 or 8099 are the network sign. Lookups to ifconfig.me or api.ipify.org on their own mean nothing. Those are normal services.

If anything turned up, use Cursor's cleanup scripts: remediate-macos.sh and remediate-windows.ps1. They're short and readable, so skim them before you run them. They unload the startup items, kill the tunnel processes, delete the tampered extension folder and dropped files, and remove the attacker's key. If anything is left over, they exit with an error.

On macOS, run it as your normal user, not with sudo:

bash remediate-macos.sh

On Windows, close every editor first, then run it from PowerShell opened as Administrator. It cleans every user profile on the machine:

powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1

A few things I'd keep in mind:

• Don't just delete the line with grep. Cursor's scripts point out that the key is appended without a newline first, so it can end up on the same line as one of your real keys. Something like grep -v svc-telemetry could take your own key out with it. The scripts handle that case.
• If it's a work machine, tell security first. Cursor recommends isolating affected hosts, and StepSecurity recommends collecting evidence before you remove anything. If the tunnel actually connected, which mostly means you ran the editor as admin, rebuilding the machine is safer than cleaning it.
• On Windows, check the admin keys file yourself. Cursor's check looks at C:\ProgramData\ssh\administrators_authorized_keys, but the cleanup script only edits each user's own authorized_keys. If the key turns up in the admin file, take it out by hand, keeping the same-line issue above in mind.

Once the machine is clean, update Claude Code from the Extensions panel. Cursor asked all customers to move to 2.1.314. The clean 2.1.314 showed up on Open VSX around 8:07 PM CDT on October 29, and StepSecurity checked 2.1.312 and 2.1.314 and says neither has the backdoor code.

The payload sent the names of your environment variables, not their values. That still tells an attacker which keys you have. Cursor also points out that the small amount of data collected doesn't rule out someone grabbing more over the backdoor later, on machines where it worked.

So if the key was on a machine, rotate from a different, clean machine: SSH keys, GitHub or GitLab tokens, cloud keys, CI tokens, package registry tokens and whatever is in your .env files. My API key rotation runbook walks through doing that without taking your apps down.

This is the part people skip. Do the key check on every machine where you run Cursor: the laptop, the desktop, the old machine in the closet. If your team uses Cursor, send them this post or the notice.

Then think about your servers. If you work like I described in last night's Remote-SSH post, you have a ~/.ssh/config full of hosts and a private key that opens all of them. An affected laptop is a laptop whose keys you should assume are known. Rotate those SSH keys, remove the old public key from each server's authorized_keys, and while you're logged in, run the same svc-telemetry check there too:

grep -n svc-telemetry ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

Cursor's notice only covers the Mac and Windows builds, and I haven't seen a report of the key showing up on a remote server. But it costs nothing to check, and it's a good excuse to clean out old keys you forgot about.

You'll probably see takes today saying this proves AI coding tools are dangerous. I don't buy it. The AI didn't do anything here. Someone tampered with an extension package in a store, the same way people have poisoned npm packages, PyPI packages and Composer dependencies. The extension happened to be an AI one because those are popular right now, and attackers go where the installs are.

The lesson is the same one as the AI agent that tried to get into a GitHub project: your tools are only as trustworthy as the supply chain they come from. Credit to Cursor here, too. They pulled it, shut the whole marketplace down instead of hoping, published exact indicators and scripts I could actually read, and said how many people were affected. That's what a good incident response looks like.

I'm still using AI in my editor every day. I'm just also going to run ssh-keygen -lf ~/.ssh/authorized_keys more often than I used to.

I use VS Code, not Cursor. Am I affected?
Anthropic says no. It says this only hit the extension as hosted on Cursor's marketplace, not the official VS Code Marketplace or Open VSX, and OpenSourceMalware's updated write-up agrees. Rescana found the Microsoft Marketplace version list goes from 2.1.312 to 2.1.314. If you're not sure where an install came from, the key check takes five seconds.

Is the Claude Code command-line tool affected?
No sign of it. OpenSourceMalware says the npm @anthropic-ai/claude-code package isn't malicious, and npm never had a 2.1.313.

I never actually used Claude in Cursor that day. Am I fine?
Not necessarily. The code ran when the editor loaded the extension. If it was installed and updated to 2.1.313 during the window, run the checks.

The attacker's server is offline. Do I still need to clean up?
Yes. The startup items keep retrying, and the key in authorized_keys would let the attacker in if SSH is ever turned on. Cursor says to remediate either way.

Should I stop using AI extensions?
No. Keep the list of extensions short, know what each one is, and pay attention when your tool vendor posts a security notice. That advice was true before AI too.

If you want a hand checking your machines and servers, or setting up a development workflow that's harder to poison, get in touch.

• Cursor, "Security notice: malicious version of Anthropic.claude-code (2.1.313) identified in the Cursor Extension Marketplace" (October 29, 2026)
• Cursor on X, incident statement and 2.1.314 update request (October 30, 2026, 2:46 AM CDT)
• Cursor, remediate-macos.sh
• Cursor, remediate-windows.ps1
• OpenSourceMalware, "Trojanized Claude Code Extension Plants an SSH Backdoor" (updated)
• StepSecurity, "Trojanized Claude Code Extension Delivered Persistent SSH Backdoor to Developer Machines" (October 30, 2026)
• Rescana, "Trojanized Claude Code Extension 2.1.313 in Cursor Marketplace Plants SSH Backdoor"
• Brandefense, "Malicious Extensions: Claude Code Playbook"
• Open VSX, Anthropic.claude-code listing
• Cursor status page, "Investigating Service Degradation with VS Code Extensions" (October 29, 2026)
• Felix Rieseberg (Anthropic) on X (October 30, 2026, 9:08 AM CDT)
• Hacker News, Anthropic engineer's comment on 2.1.313 and 2.1.314 (October 30, 2026)

Facts as of about 11:30 AM CDT, October 30, 2026.