Claude Code extension backdoor in Cursor: what happened, how to detect it and how to clean up

Anyone who installed or updated the Claude Code extension from Cursor's extension marketplace between 2.27am and 1.35pm Pacific time on 29 October 2026 received a build Anthropic never published. The identifier was the genuine one, anthropic.claude-code, and the extension behaved normally. A loader ran before the genuine code, though, left behind an attacker-controlled SSH credential and enough persistence to outlive a reboot, and tried to open a reverse tunnel to the attacker's server.

Cursor's security notice names versions 2.1.312 and 2.1.313 for Windows and macOS as malicious. According to Help Net Security, the company puts the exposure at no more than 5,000 users and will contact them directly. Anthropic says its own systems were not breached and that its official channels, the Visual Studio Marketplace and Open VSX, were unaffected. "This only impacts Cursor users," said Anthropic's David Dworken, in comments quoted by The Hacker News.

Where did the tampered build come from?

The tampered build came through the extension marketplace that Cursor runs, and nobody has yet explained how it got there. Cursor is a fork of VS Code, but the terms of Microsoft's marketplace bar forks from using it, so they draw on Open VSX or on a separate catalogue such as Cursor's. Ax Sharma of Manifold Security put the problem in one line quoted by Help Net Security: "Checking the publisher name doesn't help when the publisher is real."

Early reporting pointed to other channels. One of the first write-ups, from OpenSourceMalware, placed the build on Open VSX, and a post by one of the firm's co-founders mentioned npm and Microsoft's marketplace. Socket went through the Open VSX change feed, 3,392 events from 27 October onwards, and found no publication or removal of 2.1.313, which is also absent from npm. The original report has since been revised and no longer names Open VSX as the channel. Microsoft's analysis of the code confirms that the Visual Studio Marketplace and npm packages were not affected.

Version 2.1.312 complicates any inventory. Socket records its npm publication on 27 October and active builds on Open VSX, while Cursor counts it among the malicious builds in its store. Everything suggests the same number can be clean or tampered depending on the marketplace it came from, so each machine's record needs both the installed version and its source.

How did the injected code work?

The injected code gathered details about the machine, opened SSH access for the attacker and made sure it would start again after every reboot, all with the privileges of whoever opened the IDE. Microsoft walks through the chain step by step. Errors were swallowed and the extension carried on working, so the developer saw no change.

What data did it collect?

On load, the code gathered the hostname, username, operating system, architecture, home and working directories, and the global Git email address. It also listed the names, without the values, of up to 40 environment variables containing strings such as TOKEN, SECRET, PASS or AWS. Knowing that a machine holds a GITHUB_TOKEN or AWS credentials does not hand over the secret, but it tells the attacker which laptops are most interesting once the tunnel is up. According to Cursor, the report also included the public IP address, and everything left over unencrypted HTTP.

What were the SSH credential and the reverse tunnel for?

The credential and the tunnel gave the attacker a way into the laptop from outside. The code looked for an svc-telemetry marker in the authorized_keys file and, finding none, appended an Ed25519 public key carried inside the payload. It then tried to switch on the local SSH service and built a reverse tunnel to an attacker server, making the laptop's port 22 reachable from that server without any change to the perimeter firewall. On macOS and Linux it used autossh, falling back to plain ssh; on Windows, a hidden PowerShell loop retried the connection every 60 seconds.

Enabling SSH requires administrator rights, and Cursor explains that the step fails on most macOS and Windows machines unless the editor was started with those rights. The analysis by Phorion cited by Sophos puts those failures down to coding errors. That does not make the clean-up any less urgent. The planted credential and the persistence are written regardless, the host details are sent, and on a machine with remote SSH login already enabled the backdoor was ready to use, as Phorion's Calum Hall told Help Net Security.

How did it survive reboots?

To relaunch the tunnel, the loader installed a different mechanism on each operating system. The names mimic legitimate monitoring tools, and Microsoft advises checking what each entry runs before trusting what it is called. Linux handling is present in the code even though Cursor only lists affected packages for Windows and macOS.

Why did the usual controls miss it?

The usual controls missed it because the build carried the legitimate publisher's name and ran inside a trusted program. The first test most organisations apply to an extension is the reputation of its publisher, and here the identifier was Anthropic's. A publisher allowlist, such as the one Cursor supports through its AllowedExtensions policy, would have let this build through at any company that had approved the anthropic publisher. Microsoft recommends restricting extensions to approved publishers, but together with an installation cooldown for new versions.

Signature and reputation checks had little to go on. The code runs inside a signed IDE, and its actions, such as adding an SSH entry, creating a scheduled task or launching ssh, are routine work for any systems administrator. Microsoft lists behavioural detections in Defender for Endpoint, among them suspicious activity originating from a code editor, suspicious addition of an SSH key and suspicious SSH tunnelling.

Automatic updates did the attacker a favour. An extension that updates itself pulls each new build soon after it appears, and in an eleven-hour window the build reached up to 5,000 users, by Cursor's count.

Ten days earlier, on 19 October, the same gap showed up in a different channel. An attacker replaced the binaries on five existing releases of OVHcloud's command-line tool on GitHub, along with the checksums file so the hashes still matched. A customer's CI job that pinned the archive's SHA-256 caught it within two hours, according to OpenSourceMalware's timeline.

Name, version and download URL looked right in both incidents. With OVHcloud, the customer who raised the alarm had an integrity reference held outside the compromised channel; with Cursor, there is no sign anyone had one. The tampered AOMEI Backupper updates followed the same script. Against a supply chain attack on the distribution channel itself, the most reliable check is against a reference the attacker does not control.

How can defenders spot it in EDR telemetry?

The search starts with a list of every machine that installed or updated the extension from Cursor's marketplace on 29 October. The first two queries are our own and the last two adapt Microsoft's, which also include queries for network connections and changes to the macOS LaunchAgent. Any hit is a lead to investigate, not proof of compromise.

Writes to authorized_keys initiated by the editor's processes:

DeviceFileEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("authorized_keys", "administrators_authorized_keys")
| where InitiatingProcessFolderPath has "cursor" or InitiatingProcessParentFileName has "cursor"
| project Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

ssh or autossh processes opening a reverse tunnel to local port 22:

DeviceProcessEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("ssh", "ssh.exe", "autossh")
| where ProcessCommandLine contains_cs "-R" and ProcessCommandLine contains "localhost:22"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Windows scheduled tasks used for persistence, matching the documented name:

DeviceEvents
| where Timestamp > datetime(2026-10-29)
| where ActionType == "ScheduledTaskCreated"
| where tostring(AdditionalFields) has "SysMon" and tostring(AdditionalFields) has "smt"
| project Timestamp, DeviceName, AdditionalFields, InitiatingProcessFileName

Persistence files and hidden temporary credential files on all three platforms:

DeviceFileEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("com.apple.sysmond.plist", "sysmon.cmd", "smt.cmd", ".smt", ".smtk", "smtk") or FileName startswith ".stk_"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName

On the network side, the most useful indicator of compromise is outbound traffic to 134[.]209[.]82[.]225, the attacker's server according to Cursor's notice, on port 22 for the tunnel and port 8099 for the host report. Cursor's notice also carries hashes for the malicious packages and the fingerprint of the planted credential, and it was updated on 30 October to update indicators and add 2.1.312.

Retention sets a deadline. Defender XDR advanced hunting keeps 30 days of data, so 29 October can only be reviewed there until around 28 November unless the telemetry also lands in a SIEM. On Linux laptops without an agent, the check comes down to the user's crontab and the authorized_keys file.

Where the scope is unclear, the job looks more like a threat hunting exercise than a single alert, because what matters is reconstructing what each machine did after the extension loaded.

What should happen on an affected machine?

On an affected machine, the evidence has to be preserved, the planted credential and persistence removed and, if there are signs of access, credentials rotated. Uninstalling the extension does not remove the added SSH entry or the startup items, and nor does updating to 2.1.314, which Anthropic published on npm at 00:12 UTC on 30 October, according to Socket. Cursor and Microsoft agree that the persistence lives outside the extensions directory, and the fact that Cursor has had the attacker's server taken offline by its hosting provider does not restore the endpoints either.

• Evidence is collected before clean-up: the extension package, the modified SSH files, the generated keys and scripts, and the startup configuration.
• In authorized_keys, and administrators_authorized_keys on Windows, the svc-telemetry entry is located, its fingerprint compared with the one Cursor publishes, and that line alone removed.
• Each scheduled task, LaunchAgent or crontab entry is judged by the command it runs, and confirmed ones are deleted along with any .stk_ files.
• Related ssh or autossh processes are stopped, and after a reboot the machine is checked again to confirm nothing has returned.
• If telemetry suggests access, the credentials and sessions reachable from that laptop are rotated from a different device, including cloud keys, GitHub tokens and the secrets behind the listed variables. Many belong to non-human identities whose permissions can go beyond what the developer needs.

Cursor has published check and clean-up scripts for macOS, to be run as the affected user, and for Windows, which needs an administrator console. Microsoft suggests reading them before running them, which is sound advice for a script that arrives mid-incident. Cursor and Microsoft both contemplate rebuilding the machine where trust in it cannot be restored. When access is confirmed, an incident response service can establish how far the intruder got before anyone declares the laptop clean.

Which controls would have stopped this build?

The controls that would have stopped this build are those that put distance between the moment a version appears in a marketplace and the moment it reaches a laptop.

• A cooling-off period before new versions install, which Microsoft explicitly recommends for Cursor, would have kept out 2.1.313, which was live for about eleven hours. For 2.1.312 it would depend on whether Cursor served it as a new listing or as a replacement for the existing release.
• Extension auto-updates can be switched off through VS Code's extensions.autoUpdate user setting and routed through a reviewed process, although enforcing it as policy in Cursor should be tested first.
• Pinning exact versions helps, with a caveat. VS Code's documentation lets extensions.allowed tie an extension to specific releases, with an entry that maps anthropic.claude-code to a list of approved versions. That would have blocked 2.1.313, but not a 2.1.312 served from Cursor's catalogue. Cursor's documentation describes AllowedExtensions with boolean values per publisher or extension and does not mention versions, so pinning there should be tested on a lab machine first.
• A private marketplace or internal mirror, which Cursor supports via ExtensionGalleryServiceUrl, admits only reviewed versions.
• An inventory of VS Code forks closes a common gap. Plenty of organisations govern VS Code extensions closely without knowing how many laptops run Cursor, Windsurf or another fork with its own catalogue and policy settings.

AI coding extensions and agents work with wide access to their user's code and credentials, as Plugin4Shell's bypass of commit pinning in agent plugins and the npm worm that hooked into Claude Code have already shown. This incident makes the case for treating developer workstations as high-value assets and for extending DevSecOps practice to the tools developers install. An older control than any of these is to leave the SSH service switched off on laptops that do not need it.

Is it known yet how the build reached Cursor's marketplace?

It is not known as of 2 November, because Cursor has not published a root cause. Its notice says it removed the build, took the marketplace down as a precaution, rebuilt it, audited access, rotated keys and confirmed that no other extension had been altered. Until it explains how the build was published, an extension marketplace operated by a third party deserves to be handled as a supplier, with its own third-party risk assessment, and not as a neutral mirror of the original.

For a security lead, the practical measure is how many hours a new extension version takes to reach staff laptops, and who reviews it on the way.

Sources and attribution: this analysis draws on public information available on 2 November 2026. The main sources are Cursor's security notice, Microsoft Threat Intelligence's analysis, Socket's registry review and OpenSourceMalware's report, alongside coverage by Help Net Security, Sophos and The Hacker News, which carry the statements from Anthropic, Cursor and Phorion. How the malicious build was published has not been disclosed, and naming Cursor and Anthropic implies no flaw in their products beyond what they have themselves stated. Details on affected versions and indicators have changed since first disclosure and may change again.

Note: the KQL queries, indicators and configuration settings are illustrative, should be adapted to each environment and tested before use in production. Indicators come from third parties, may expire and should always be checked against the original sources.