28creation
Newsletter
News Developer tools

Claude Code 2.1.313 in Cursor: uninstalling leaves the backdoor

A modified Claude Code build reached up to 5,000 Cursor users on October 29. Its SSH key and startup scripts can outlast the extension.

By 28creation Desk 3 min read

The short read

Uninstalling the bad Claude Code build can leave its SSH key and startup scripts in place, Cursor and Phorion warn.

  • A modified Claude Code 2.1.313, not made by Anthropic, sat in Cursor's marketplace for about 11 hours and reached up to 5,000 users.

What you can do with this

On every machine that runs Cursor, search ~/.ssh/authorized_keys for svc-telemetry. If it is there, run Cursor's cleanup script and rotate the keys and tokens that machine holds.

Two hands resting on a dark backlit laptop keyboard, the keys lit white against the black body.
Photo: Colin, CC BY-SA 4.0

Cursor said on October 29 that a modified Claude Code extension, version 2.1.313, “not developed by Anthropic,” was in its extension marketplace from about 09:27 to 20:35 UTC that day and reached at most 5,000 users. The security firm Phorion found it; Help Net Security and StepSecurity followed.

If anyone on your team runs Cursor with Claude Code, updating the extension is not enough. Cursor writes that “uninstalling the extension may not be sufficient,” because the payload leaves scripts that keep running. Phorion says the same: removing the extension does not remove the backdoor.

The code ran before the extension started

Phorion found a prefix added to the extension’s minified extension.js. It runs when the editor loads the file, before the extension’s own start code, with no click from the user.

Per Cursor’s notice, it sent host and user details to the attacker’s server at 134.209.82.225. It then tried three things.

It tried to add an SSH key labeled svc-telemetry to authorized_keys, turn on SSH, and open a reverse SSH tunnel so the attacker could log in from outside. A LaunchAgent named com.apple.sysmond on macOS, or a SysMon scheduled task and Startup script on Windows, retried the tunnel about every 60 seconds.

Phorion adds what the first message carried: host details, the Git email, the public IP and the names of up to 40 environment variables that look like credentials. The values were not sent. The names alone still tell an attacker which keys a machine holds.

Most machines blocked the worst step

Turning on SSH “requires admin rights,” Cursor writes, which the extension “does not have on most macOS and Windows hosts.” The attacker’s server is now offline, taken down with the hosting provider’s help. So on most laptops, by Cursor’s account, the remote login would have failed.

But the key and the startup scripts could still be written. On a machine where SSH was already on, a key in authorized_keys is a working login. We treat any hit as a compromise, as Cursor does.

Where it came from is not settled

Cursor’s notice says nothing about how the build got into its marketplace. StepSecurity says it was published to Open VSX, the Eclipse Foundation’s registry, and copied into Cursor’s store. Ax Sharma of Manifold Security, quoted by Help Net Security, says the poisoned listing was Cursor’s own. Neither article carries a statement from Anthropic.

We checked both public registries at 15:18 UTC on October 30. Open VSX answers “Extension not found” for 2.1.313 and lists 2.1.314, published at 01:07 UTC that day. The npm package jumps from 2.1.312 to 2.1.314 and has no 2.1.313 at all.

Cursor lists tampered builds only for Apple silicon Macs and 64-bit Windows and does not mention Linux. Phorion’s analysis says the code also has a Linux branch that adds an @reboot cron entry.

What to do now

  1. Check for the key on every machine that ran Cursor on October 29: grep -qs svc-telemetry ~/.ssh/authorized_keys && echo found. On Windows, Cursor also checks C:\ProgramData\ssh\administrators_authorized_keys.
  2. On Linux, run crontab -l and look for an @reboot line you did not add, plus ~/.config/.smt and ~/.config/.smtk. Cursor’s two scripts do not cover Linux.
  3. If you find anything, run Cursor’s script: remediate-macos.sh as the affected user, not root, or remediate-windows.ps1 as Administrator. Both are linked from the notice.
  4. Rotate from a clean machine the SSH keys, cloud keys and tokens the affected account could read. Start with the variables whose names matched the attacker’s list.
  5. Update the extension to 2.1.314 and block 134.209.82.225 on ports 22 and 8099 at the firewall.

A clean grep is the answer most teams will get. A hit means a login key on a developer laptop that nobody on your team put there, and the extension update alone will not remove it.

Sources

Read next

  1. News Developer tools

    GitBook breach exposed Git Sync secrets: what to rotate

    An attacker may have read GitBook's integration tokens and Git Sync secrets. For GitLab users that includes a token with write access to the repo.

    28creation Desk 3 min read

  2. News Developer tools

    Trigger.dev breach exposed environment variables: what to rotate

    An attacker read secrets stored by some Trigger.dev customers. Any API key your jobs use there should be replaced at the provider that issued it.

    28creation Desk 3 min read

  3. News Developer tools

    DeepSeek's open coding agent runs commands with full user access

    DeepSeek's open-source coding agent for GitHub teams runs commands without approval as your OS user. Give it its own accounts before you try it.

    28creation Desk 3 min read