Claude Code Extension Backdoor on Cursor: How to Check and Clean Up

If you use Cursor and had Anthropic's Claude Code extension installed on October 29, 2026, check your machine now. Cursor confirmed that malicious builds of Anthropic.claude-code 2.1.312 and 2.1.313 were live in its VS Code Extension Marketplace for macOS and Windows from about 2:27am to 1:35pm PT that day. The builds tried to plant an attacker's SSH key, set up a persistent reverse SSH tunnel and send host details to a remote server. Updating or uninstalling the extension does not remove that persistence. Run the checks below, clean up, and rotate any credentials the machine could reach.

This guide pulls together what Cursor, Anthropic and the researchers who analysed the payload have confirmed, notes where their accounts differ, and lists what to do on your own machine and across a team.

What happened, in brief

The tampered update was first reported by Phorion, an endpoint detection vendor, in an advisory published October 30, 2026. Code had been prepended to the extension's extension.js bundle, so it ran as soon as the editor loaded the extension, before the normal activate callback. No click or prompt was needed.

Cursor's security notice confirms the builds were "maliciously modified", were not made by Anthropic, and affected Windows and macOS. Cursor says it removed the version, shut down the whole marketplace temporarily, audited access, found no other tampered extensions, rotated keys and worked with the hosting provider to take the attacker's server offline. Cursor updated its indicators on October 30 at 11:30am PT and clarified that 2.1.312 was affected too, not just 2.1.313.

According to The Register, Cursor's initial figure was up to 5,000 affected developers. Anthropic's Felix Rieseberg said there was "no compromise of Anthropic's systems or employee laptops" and that "the versions on our official channels are not affected, and this only impacts Cursor users." As of October 31, neither company has publicly explained how the package got into Cursor's marketplace.

Where the accounts differ

Early write-ups, including Phorion's original advisory, described this as an Open VSX compromise. StepSecurity's updated analysis corrects that. It says the 2.1.312 build on Open VSX is clean (StepSecurity verified it), 2.1.313 was never published to Open VSX, and Anthropic says 2.1.313 never reached Microsoft's marketplace. Some secondary coverage still names Open VSX. Go by Cursor's notice and StepSecurity's correction: the malicious bytes came from Cursor's marketplace.

What the payload actually did

Phorion's analysis describes four stages:

1. SSH key implant. Creates ~/.ssh if needed and appends an attacker Ed25519 public key with the comment svc-telemetry to authorized_keys, then tries to enable the local SSH server.
2. Reverse tunnel. Opens an outbound SSH connection to 134.209.82.225 as user tunnel with -R *:0:localhost:22, which would give the attacker a path back into your SSH daemon. It retries every 60 seconds and runs detached, so it keeps going after you close the editor.
3. Persistence. On macOS, a LaunchAgent at ~/Library/LaunchAgents/com.apple.sysmond.plist that runs ~/.config/.smt, named to look like an Apple component. On Windows, a scheduled task called SysMon with a Startup folder fallback (sysmon.cmd). On Linux, an @reboot cron entry.
4. Recon beacon. A one-time plaintext HTTP POST to 134.209.82.225:8099/beacon with your hostname, username, OS, home and working directories, global Git email, public IP, and the names of up to 40 environment variables matching KEY|TOKEN|SECRET|PASS|AWS|GCP. Phorion says the values were not sent.

The payload also had bugs. Cursor says the tunnel and SSH-enable steps usually fail because they need admin rights the extension typically doesn't have on macOS and Windows. Phorion found that the macOS Remote Login check never matches when run without admin rights, and that the Windows path calls a helper hardcoded to /bin/sh. That doesn't mean you can skip cleanup. The key and persistence still got written, the beacon didn't need admin rights, and the persistence loop keeps retrying. Phorion also warns that a crontab bug on Linux can wipe a user's existing cron jobs on repeat runs, so Linux users should check their crontab even though Cursor lists only macOS and Windows as affected.

How to check if you're affected

Start with the simplest check: the attacker key. These commands come straight from Cursor's notice.

macOS / Linux:

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

Windows (PowerShell):

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

Then look for the other artifacts listed by Cursor, Phorion and StepSecurity:

• Extension folders: anthropic.claude-code-2.1.312-* or anthropic.claude-code-2.1.313-* under your editor's extensions directory. Search their extension.js for 134.209.82.225 or svc-telemetry.
• macOS: ~/Library/LaunchAgents/com.apple.sysmond.plist, ~/.config/.smt, ~/.config/.smtk, $TMPDIR/.stk_<10 hex chars>.
• Windows: scheduled task SysMon, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd, ~/.config/smt.cmd, ~/.config/smtk.
• Linux: an @reboot entry in crontab -l, ~/.config/.smt, /tmp/.stk_*.
• Processes and network: ssh -N -R or autossh -M 0 processes, outbound SSH to 134.209.82.225, HTTP POSTs to port 8099, and SSH logins from 127.0.0.1/::1 using the svc-telemetry key.

The extension.js SHA-256 from Phorion is ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15. Cursor's notice also publishes hashes for the darwin-arm64 and win32-x64 VSIX packages. Because Cursor revised its indicators on October 30, compare against the current list there rather than copies on third-party sites.

Calls to ifconfig.me or api.ipify.org on their own don't mean much. StepSecurity points out that both are legitimate services.

How to clean up

Use Cursor's scripts

Cursor publishes remediation scripts that remove the extension, persistence, tunnel processes and the attacker key, and exit non-zero if anything is left behind. Download them only from the links in Cursor's notice, and read them before running.

• macOS: run remediate-macos.sh as the affected user, not root: bash remediate-macos.sh.
• Windows: in an Administrator PowerShell, run powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1.

There's no Linux script. If you find the Linux artifacts above, remove them by hand.

The full response, in order

Combining the guidance from Cursor, Phorion and StepSecurity:

1. Collect evidence first if you have a security team: copy the plist or task definition, the .smt files and the extension folder before deleting anything.
2. Kill the loop: stop the /bin/sh retry process and any ssh/autossh connecting to 134.209.82.225.
3. Remove persistence: unload and delete the LaunchAgent, scheduled task, Startup script or cron entry, plus ~/.config/.smt* and .stk_* files.
4. Clean SSH: delete the svc-telemetry line from authorized_keys and confirm Remote Login / OpenSSH Server is off unless you actually use it.
5. Update the extension to 2.1.314 or later. StepSecurity notes that Cursor has replaced the bad 2.1.312 bytes, so reinstalling now shouldn't reinfect you.
6. Rotate credentials from a clean machine: source control tokens, CI/CD secrets, cloud keys, SSH keys, package registry tokens, and especially anything whose variable name the beacon would have captured. Cursor warns that the limited environment-variable collection "does not rule out" later credential access over the backdoor.
7. Rebuild instead of cleaning if there's any sign the tunnel connected or an inbound SSH login happened.

If your LLM API keys lived in shell env vars on that machine, rotating them is a good moment to set spend limits too. Our guide to hard budget caps on cloud and LLM APIs covers how.

What this changes for teams building with AI IDEs

The extension was legitimate and widely trusted. The tampering happened at the distribution layer: a fork-specific marketplace sitting between the publisher and the user. Every VS Code fork that runs its own extension registry adds one more place where this can happen. Some practical changes:

• Know which registry each editor pulls from. VS Code, Cursor and other forks may serve "the same" extension from different backends with different controls. Your checks should cover the registry you actually install from, not just the publisher.
• Slow down auto-updates for high-privilege extensions. Coding-agent extensions can read your repo, run shell commands and see your environment. Consider turning off automatic extension updates on machines that hold production credentials, and updating deliberately after a short delay. This attack's exposure window was about 11 hours.
• Get secrets out of your shell environment. The beacon went looking for names like AWS_SECRET_ACCESS_KEY and GITHUB_TOKEN. Short-lived credentials from a secrets manager or SSO-based CLI auth limit the damage when a dev box gets popped.
• Alert on the behaviours, not just this campaign's indicators. Phorion's suggested detections apply well beyond this incident: IDE helper processes writing to authorized_keys, non-Apple processes creating com.apple.* LaunchAgents, and ssh -R reverse tunnels started from editor process trees.
• Keep an inventory of installed extensions and versions across the team, so a "were we affected?" sweep takes minutes rather than a day of Slack polling.

The same pattern showed up in the LiteLLM 1.107.0 PyPI compromise and the AGENTS.md Downloads folder attack: attackers go after AI developer tooling because it runs with broad local access on machines full of credentials.

What to watch next

The big open question is how the attacker got publishing access to Cursor's marketplace. Neither Cursor nor Anthropic has said, and that answer will show whether other fork-run registries share the same weakness. Watch Cursor's notice for further IOC revisions, and treat the 5,000-user figure as Cursor's initial estimate rather than a final count.

What to do today: run the key check on every Mac and Windows machine that had Cursor plus Claude Code installed on October 29, clean up any hits with Cursor's scripts, rotate credentials from a clean device, and rebuild any machine where the tunnel may have connected.