Ran the Claude Code extension in Cursor on 29 October? Check for one SSH key, then check whether anyone used it

Between about 02:27 and 13:35 Pacific time on 29 October (09:27 to 20:35 UTC), the Cursor VS Code extension marketplace served tampered builds of Anthropic's Claude Code extension, versions 2.1.312 and 2.1.313 for macOS and Windows. Cursor's security notice says Anthropic did not build them, and that it has "no evidence that other versions of the extension or the official distribution are affected." Early reports that named npm, Open VSX and Microsoft's Visual Studio Code Marketplace were wrong; BleepingComputer later confirmed that Cursor was the only source distributing the tampered builds.

If you had the extension in Cursor that day, on either platform, run this on a Mac (it is Cursor's own check):

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

On Windows, Cursor's PowerShell version also reads the file that administrator accounts use:

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

"No key found" on every machine that ran Cursor that day means you can stop here.

The version number will not tell you

The tampered bundle carries the same version string as a real release. Cursor's cleanup script says so in a comment: "The tampered bundle keeps the real version number, so match on content." If you still have a copy of the extension installed anywhere, check the file itself:

grep -l svc-telemetry ~/.*/extensions/anthropic.claude-code-*/extension.js 2>/dev/null

Any path printed is a tampered copy. In zsh, a no matches found message means no copy of the extension exists in any editor folder, which is also a clean result.

If the key is there, uninstalling is not enough

The malicious code was placed at the top of extension.js and ran when the editor loaded the extension, before anything you could click. According to Phorion's analysis, which matches the indicators in Cursor's notice, it did four things outside the extension folder:

• appended an Ed25519 key with the comment svc-telemetry (fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk) to ~/.ssh/authorized_keys
• started a reverse SSH tunnel to 134.209.82.225 that forwards back to port 22 on your machine, retrying every 60 seconds
• sent your hostname, username, OS, home and working directory, global Git email, public IP, and the names (not the values) of up to 40 environment variables matching KEY, TOKEN, SECRET, PASS, AWS or GCP
• installed itself to survive a restart

Removing the extension deletes its folder and none of the above. Cursor publishes cleanup scripts for macOS (run as the affected user, not with sudo) and Windows (run as Administrator). Read the macOS script before running it; it is about fifty lines. It unloads the launch agent, kills the tunnel processes, deletes tampered extension folders in every ~/.<editor>/extensions directory, removes the dropped files, and cuts the attacker key out of authorized_keys without touching the key it may share a line with (the key was appended without a leading newline). It exits 1 if anything is left behind.

Cursor says it has taken the attacker's server offline, so a tunnel running now connects to nothing. That does not cover the hours before the takedown.

Was Remote Login already on?

The tunnel only gives someone a shell if an SSH server is listening on your machine. The payload tried to switch one on, and both Cursor and Phorion describe that step as failing on a normal user account: on macOS the check it relies on prints an administrator-access error instead of "Off", and on Windows the setup path calls /bin/sh. Cursor concludes that on most hosts "the attacker could not have logged in through the tunnel."

That conclusion assumes SSH was off. Phorion makes the other case explicit: "If the user already had Remote Login enabled, or turns it on later, the backdoor is ready and waiting." Developers who SSH into their own Mac from another machine are in that group. Check:

sudo systemsetup -getremotelogin
nc -z -G1 127.0.0.1 22 && echo "something is listening on port 22"

Remote Login also appears in System Settings under General, Sharing. On Windows, Get-Service sshd returns a service only when OpenSSH Server is installed.

Did anyone log in?

A login through the tunnel arrives from 127.0.0.1 or ::1, because the tunnel ends on your own machine, and it authenticates with the attacker key. OpenSSH writes the key fingerprint on every accepted login, so search for it. On macOS, call log by its full path, because in zsh (the default shell) log is a built-in command and the bare word fails with "too many arguments":

/usr/bin/log show --start "2026-10-29 00:00:00" --info \
  --predicate 'process == "sshd" OR process == "sshd-session"' \
  | grep "0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk"

On Windows with OpenSSH Server installed:

Get-WinEvent -LogName 'OpenSSH/Operational' | Where-Object { $_.Message -match '0Z6R\+DF64Do2nwQic8a7kkfDLNNk4IiK\+2U2Rci4htk' }

The macOS unified log does not keep entries indefinitely, so run this soon. No output while SSH was off is the expected result. Output of any kind means someone had a shell on the machine as your user.

What to rotate

Cursor's last step applies whenever the key was present: "Rotate credentials and sessions accessible from affected hosts, from a trusted system." Do it from another machine, since the affected one may still be reachable. Start with the secrets whose variable names were sent, because the attacker now knows those exist on that machine: cloud keys, API tokens, anything named *_SECRET or *_PASSWORD. If Remote Login was on or the log search returned a line, treat everything the user account could read as exposed, including SSH keys in ~/.ssh, Git credentials, browser sessions and the .env files in your repositories, and decide whether to rebuild the machine. Cursor recommends weighing a rebuild for any host that shows the payload ran.

The places to look after any malicious extension or package

The same pattern shows up in most malicious packages: the installable thing is a carrier, and the persistence lives elsewhere, so removing the package is not cleanup. This incident used three of the usual spots, and they are worth knowing by heart:

Where	macOS / Linux	Windows
Remote access	~/.ssh/authorized_keys	%USERPROFILE%\.ssh\authorized_keys, C:\ProgramData\ssh\administrators_authorized_keys
Runs at login	~/Library/LaunchAgents/ (here com.apple.sysmond.plist), crontab -l on Linux (here an @reboot line)	Task Scheduler (here a task named SysMon), %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ (here sysmon.cmd)
Hidden files	~/.config/.smt, ~/.config/.smtk, /tmp/.stk_*	%USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_*

ls -lt ~/Library/LaunchAgents lists the newest agents first. A file named com.apple.* there deserves a second look, because Apple's own launch agents live under /System/Library, and an Apple-looking name in your user folder is a common disguise.

The broader point for extensions that run agents: an editor extension runs as your user, with access to the same home directory, keys and environment variables as your terminal, and it can update itself silently. We wrote about the related problem for agent skills in audit your agent skills and pin the source, and about what a sandbox setting leaves open in what an agent sandbox rule does not cover.

Cursor has not said how the tampered builds reached its marketplace, and Anthropic has not published a statement. If you find the key and need help, Cursor asks affected users to write to [email protected].