Claude Cursor extension SSH backdoor: what failed in trust and what to review

The Claude Cursor extension SSH backdoor reached development teams as a routine update. It was published under the official publisher's identity, not as an imitation. That detail makes the incident more than a one-off news item.

For a technical team, it is not enough to know whether someone installed version 2.1.313. You need to understand how a trust as reasonable as «it's the official extension» could be exploited, and which controls are missing so that the next time does not depend on luck.

An update with a legitimate identity tried to install a persistent backdoor

According to The Hacker News, a trojanized Claude Code extension, version 2.1.313, was distributed through the Cursor Marketplace. It arrived as a legitimate update under the original publisher's identifier, anthropic.claude-code, rather than as a separate fake extension [1]. Its goal was to leave a persistent SSH backdoor on the machines where it was installed. Cursor temporarily shut down its marketplace to remove the package [1].

Help Net Security attributes the discovery to Phorion, a security firm specializing in macOS [2]. Atlabyte adds that researchers from OpenSourceMalware also took part [3]. The sources agree on the mechanics: a malicious JavaScript loader inserted at the start of the extension's main file, with the rest of the legitimate code left unchanged. That loader runs as soon as the extension loads, without the user having to interact with it [2] [3].

According to the analysis reported by The Hacker News, once active, the code adds an attacker-controlled SSH key to the user's authorized keys file. It labels the key «svc-telemetry» so that it looks harmless [1]. It then tries to open a reverse tunnel to the attacker's server and to establish persistence on each system. On Windows it tries to create a scheduled task and, if that fails, falls back to the startup folder. On Linux it adds a crontab entry, and on macOS it installs a LaunchAgent [1] [2]. It also sends the operator data about the machine, such as the hostname, the user, the operating system, the Git email and the names of environment variables that appear to contain keys or tokens. It sends those names, but not their values [1] [2].

This is not a curiosity of a script, but an attempt at long-term interactive access to a developer's machine.

What is confirmed and what remains unexplained

Some facts are already documented. According to Atlabyte, the malicious version was available on 29 October 2026 between 2:27 and 13:35 Pacific time [3]. That window matches the one communicated by Cursor and reported by The Hacker News [1]. Cursor has set a ceiling on the number of affected users and has announced that it will contact them directly [1] [2]. The company also maintains that Anthropic did not develop that version [1] [3]. For its part, Anthropic has published version 2.1.314 on Open VSX and on Microsoft's Visual Studio Marketplace [1].

One factor limits the damage, although it does not remove it. Cursor explains that enabling the local SSH service requires administrator permissions, which the extension does not have on most macOS and Windows machines. In those cases, the attacker would not have been able to get in through the tunnel [1]. Phorion links the macOS failure to a badly written check. Its chief executive, Calum Hall, warns that this error is not a defense. On a Mac that already has remote login enabled, or that enables it later, the backdoor is ready to use [2]. Cursor also worked with the cloud provider hosting the attacker's server to take it offline. That cut off both the tunnel and the data exfiltration [2].

Above all, it is still unknown how the update was published under the legitimate publisher's identity. Neither The Hacker News nor Atlabyte has been able to explain it [1] [3]. Atlabyte says it will keep watching for clarification of the method and for whether any Cursor or Anthropic systems were compromised [3]. Until there is an official explanation, any hypothesis about the vector or the authorship is speculation. Cross-check the details against Cursor's security advisory and Phorion's analysis.

The early confusion over Open VSX helps explain where these extensions come from

The first reports disagreed on the channel. Help Net Security published that Phorion had located the package on Open VSX, the open-source extension marketplace for VS Code run by the Eclipse Foundation [2]. The outlet later added an update in which Ax Sharma, of Manifold Security, disputes that the Open VSX version was compromised [2]. The Hacker News corrected its reporting: the incident has been traced to the Cursor marketplace, with no evidence that it reached Open VSX or Microsoft's official marketplace [1]. Atlabyte likewise reports that Cursor was confirmed as the only source [3].

Still, the confusion illustrates something relevant. Help Net Security explains that the Visual Studio Marketplace terms of use restrict it to Microsoft products. As a result, editors built on the open-source VS Code codebase, such as Cursor or Windsurf, cannot use it and rely on other marketplaces [2]. The same extension, with the same name, can reach a developer through different channels depending on the editor they use.

If VS Code, Cursor and other derived editors coexist in your company, you need to watch several marketplaces, not one. That is the territory of software supply chain risk management. In this context, you need to know what third-party software enters the organization, through which route and with what guarantees.

The official publisher's name stopped being a reliable trust signal

Here is the core of the case. The update arrived under the publisher's legitimate identity [1] and, according to Cursor, Anthropic did not create it [3]. Ax Sharma sums it up in the Help Net Security update: there was no impersonation to detect. Checking the publisher's name does not work when the publisher is real, and what helps is monitoring behavior [2]. In The Hacker News, Jenn Gile, co-founder of OpenSourceMalware, adds another factor. Although the version was withdrawn very quickly, anyone with automatic updates enabled could have received it [1].

That leads to an uncomfortable reading: it is unwise to rely solely on a policy of «install only official extensions». This is not about blaming Cursor, Anthropic or the developers who updated. The update was distributed under the publisher's legitimate identity and still contained malicious code.

That is why trust in the publisher needs its own complementary controls. You have to know which version is installed on each machine, decide when it gets updated, and be able to react in hours, not weeks.

What to review on development machines: installed version, SSH keys and extension inventory

The steps below are general guidance. For the specific checks, follow the commands and cleanup scripts published by Cursor. Also use the indicators of compromise shared by Cursor and Phorion [2].

1. Identify the exposure. Check whether any machine with Cursor installed version 2.1.313 or updated to it. Also verify whether the date falls within the 29 October 2026 window given by the sources [1] [3].
2. Review the authorized SSH keys. Look in the authorized keys file for an entry labeled «svc-telemetry», as Help Net Security and Atlabyte recommend [2] [3]. Phorion also suggests reviewing SSH logs for logins from localhost using that key [2].
3. Do not stop at uninstalling. Phorion warns that uninstalling the extension does not remove the backdoor. Cursor notes that the code leaves behind independent scripts that keep running [2]. You have to remove the unauthorized key and the persistence mechanisms [1].
4. Treat the machine as compromised if there are signs. Cursor advises isolating affected machines and considering rebuilding them. It also recommends rotating, from a trusted system, the credentials and sessions they could access [2].
5. Set a policy for what comes next. Keep an inventory of extensions per machine and an allowlist of permitted extensions. On critical workstations, review updates instead of applying them automatically, and log what gets installed. This is general good practice, not a recommendation from the sources.

Your organization may be deploying coding assistants at scale and have doubts about the scope. In that case, a consultancy engagement to review the security of your AI development tools can help you decide which behaviors to monitor on those workstations and how to respond when something falls outside what is expected.

Adopting AI coding assistants also means governing what gets installed around them

This case is not about an AI model getting something wrong or a leak of training data. It is about something more prosaic: an extension carrying the official publisher's name can become the way in. According to Atlabyte, the Claude Code extension adds an AI assistant to compatible editors to help write and debug code [3]. In this incident, the malicious code could add an SSH key to the user's authorized keys file.

The idea worth taking away is simple: trust in AI development tools is not a given. It is managed through inventory, version control and periodic key review. The incident lasted a few hours, but the decision about who approves, who inventories and who revokes what gets installed is permanent. For companies adopting coding assistants, AI governance does not end at the model or the data. It also extends to the extensions, to the SSH keys of the people who use them, and to the marketplaces they are installed from.

If you want to bring order to that perimeter, you can look at the AI security governance solution.