Installing Claude Code From Cursor Planted Attacker SSH Keys on Up to 5,000 Machines

A trojanized build of the Claude Code extension sat in the Cursor marketplace for roughly 11 hours on October 29 and added an attacker's SSH key to the machines that installed it. An SSH key is the credential used to log into a machine remotely. Once an attacker's key is registered in the right file, there is a path into that machine with no password.

The window ran from 2:27am to 1:35pm Pacific, or 09:27 to 20:35 UTC. Cursor said on X that up to 5,000 users were affected. That number does not appear in the body of the security notice itself, and Socket wrote that it had not independently verified it. How many machines actually ended up with a working remote path has not been disclosed.

Checking only for 2.1.313 misses machines

Cursor revised the notice on October 30 and the list of trojanized versions grew from one to two. The original headline named only 2.1.313; it now reads 2.1.312 and 2.1.313. The 11:30am Pacific edit note says only that it "clarified the affected versions."

The reason this is easy to get wrong is that the official 2.1.312 is clean. The build published to npm and Open VSX on October 27 passed StepSecurity's verification. Same version number, but only the copy pulled from Cursor during that window may be trojanized. The vendor analyses and news coverage written before the revision listed 2.1.313 alone, so anyone checking against that list will miss 2.1.312 installs.

The notice draws no line between paid and free plans, and none by region. Cursor has not published a country or region breakdown of the up-to-5,000 figure, so a developer in Singapore or anywhere else in APAC cannot tell from the notice whether their market was in scope. The window itself covered a full working day across APAC time zones, which is the only regional detail the published timeline gives.

It ran the moment it was installed

Nobody had to prompt Claude for this to fire. The attacker prepended 66 lines of code to the extension's main file, extension.js. According to Phorion's analysis, that code runs the moment the editor reads the file, before the activate callback. It swallows its own errors and lets the real extension load normally, so there is nothing for the user to notice.

The diagram above is labeled 2.1.313, but Cursor's notice says the malicious file is identical in both versions. The code does four things.

• Adds a key: writes an attacker key named svc-telemetry into ~/.ssh/authorized_keys.
• Opens a path out: attempts a reverse SSH tunnel to the attacker's server, a remote-access channel dialed outward from inside the machine.
• Installs persistence: on macOS a LaunchAgent named com.apple.sysmond, styled to look like an Apple component, and on Windows a scheduled task called SysMon, retrying the connection roughly every 60 seconds.
• Sends reconnaissance: hostname, username, Git email, public IP, and working directory. For environment variables matching KEY, TOKEN, SECRET, PASS, AWS, or GCP, it collects up to 40 names only, not values.

Phorion notes that the variable names alone are enough to sort which machines hold cloud credentials. Phorion's Calum Hall described the code's goal as long-term interactive access.

A bug in the attacker's code blocked the login, but the key stayed

By Cursor's account, the attacker could not log in on most machines. Turning on a machine's SSH service requires administrator rights, and Cursor says that step failed in most macOS and Windows environments. Phorion traced the macOS failure to a coding error: run systemsetup -getremotelogin without admin rights and it returns an error string with exit code 0, the malware fails to read that as "off," and it skips the step that would have enabled remote login.

The attacker's server is down too. Cursor worked with the hosting provider to take it offline, so the tunnel and the data exfiltration do not function now.

Three problems survive that.

1. Machines with remote login already enabled are a different case. Phorion wrote that the error is not a defense: if remote login is already on, or gets turned on later, the key works. A developer machine with SSH enabled for remote work falls into this group.
2. The reconnaissance data already left. Cursor acknowledged that the key addition, the persistence install, and the host data transmission all completed.
3. Uninstalling and updating do not clean it up. The key and the persistence script live outside the extension folder, so moving to 2.1.314 leaves both in place.

Nobody has said how it got uploaded

The entry path has not been disclosed. Cursor's notice says it audited access logs, rotated keys, and rebuilt the marketplace, and that no other extension was tampered with. It does not say which credential or permission was compromised, or whether the publishing process changed to prevent a repeat.

Anthropic's position is that this was not its problem. Felix Rieseberg, an engineer there, said on X that no Anthropic system or employee laptop was compromised. Per The Register, the company said its own official distribution channels were unaffected. The complication is that the official Claude Code documentation points Cursor users at an Install for Cursor link. From where the user stands, they followed official guidance and installed an extension carrying the official name, which is why the Hacker News thread kept circling back to whether Cursor can fairly be called an unofficial channel.

The early reporting that Open VSX had been breached was also reversed. Socket searched 3,392 Open VSX change records and found no 2.1.313 entry, and OpenSourceMalware, which filed the first report, corrected its post to name the Cursor marketplace as the source. On current evidence there is little reason for users of other editors that pull from Open VSX, the open-source extension registry, to treat this as their incident.

This is the second distribution-channel attack on developer tooling this month. The LiteLLM malicious release on October 21 came through a package registry; this one came through an extension marketplace. Plugin4Shell, disclosed in September, was a flaw that let coding-agent plugins install code other than the commit they had pinned.

The command to run now

If you use the Claude Code extension in Cursor, run this on macOS to check whether the attacker key is present. The PowerShell equivalent for Windows is in Cursor's notice.

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

If the key turns up, run remediate-macos.sh or remediate-windows.ps1 from the notice, then from a different, clean machine rotate every GitHub token, cloud key, and session that the affected machine could reach. Cursor also suggests weighing a full reinstall of the machine.