The Claude Code backdoor put extension marketplace trust on trial. What are open-source tooling ecosystems doing about it?

A tampered version of Anthropic's Claude Code extension sat inside the Cursor VS Code Extension Marketplace for roughly eleven hours on October 29, 2026, attempting to install a persistent SSH backdoor on developer machines. Cursor confirmed the incident affected versions 2.1.312 and 2.1.313 for macOS and Windows. When the malicious extension was finally pulled, the community was left with a structural question that the incident made hard to ignore: the docs reviewed here do not mention cryptographic artifact signing or provenance enforcement.

What actually happened

Between approximately 2:27 a.m. and 1:35 p.m. PT on October 29, 2026, a maliciously modified version of Anthropic.claude-code was available through the Cursor VS Code Extension Marketplace, according to Cursor's security notice. The company confirmed those versions were not developed by Anthropic.

Security firm Phorion published a technical breakdown of the backdoor's mechanics. The tampered extension.js file prepended an immediately invoked function expression (IIFE) to the legitimate minified Claude Code bundle. Because the injected code executed as soon as Node.js loaded the file — before the extension's normal activate callback fired — the user needed to do nothing beyond having the extension installed and updated.

According to both Phorion's analysis and Cursor's notice, the payload:

• Appended an attacker-controlled Ed25519 public key (comment: svc-telemetry) to ~/.ssh/authorized_keys
• Attempted to enable the local SSH service and open a reverse tunnel to 134.209.82[.]225 on port 22
• Installed persistence via a LaunchAgent plist (com.apple.sysmond.plist) on macOS, a scheduled task or startup script on Windows, and a cron entry on Linux
• Sent a JSON beacon to the attacker's server at :8099/beacon containing hostname, username, OS, architecture, git email, public IP, and the names (not values) of environment variables matching /KEY|TOKEN|SECRET|PASS|AWS|GCP/i

Importantly, Cursor's notice is explicit that the SSH-enabling step would fail in most real-world conditions: "turning on the local SSH service requires admin rights, which the malicious extension does not have on most macOS and Windows hosts. On those hosts the step fails." Phorion independently found the same bug: systemsetup -getremotelogin without root privileges prints an administrator-access error and exits with status 0 rather than returning Off, so the malware's own logic skipped the SSH-enablement step entirely on standard user accounts.

The backdoor still dropped the attacker's SSH key and persistence scripts regardless. Uninstalling the extension is not sufficient — as Cursor's notice states, "the payload drops standalone persistence scripts that keep running."

Phorion includes the following example from the backdoored code, showing how the macOS SSH check was structured:

// The malware's check — fails silently on standard accounts
if (/Off/i.test(rl)) {
det("sudo -n systemsetup -setremotelogin on >/dev/null 2>&1");
d.remoteLoginOn = "tried"
}

On a standard macOS user account, rl contains an administrator-access error string, not Off, so the conditional never fires.

Cursor confirmed it worked with the cloud provider hosting the attacker's server to take it offline, "so the reverse shell and host detail POST are not functional." Reuters, cited in the Lobsters discussion thread, reported that approximately 5,000 users were affected — a figure Cursor's own notice does not confirm directly.

The three-layer marketplace architecture

Understanding the incident requires understanding how Cursor's extension ecosystem is structured.

Microsoft operates the Visual Studio Marketplace, accessible only from VS Code builds that include Microsoft's proprietary licensing. Cursor, like other open-source VS Code forks, cannot use that marketplace. Instead it relies on Open VSX, an Eclipse Foundation project that operates as a vendor-neutral open-source registry. According to the Eclipse project page, Open VSX "provides a server application that manages VS Code extensions in a database, a web application similar to the VS Marketplace, and a command-line tool for publishing extensions."

Cursor layers its own marketplace on top of Open VSX, adding a curated set of extensions not present in Open VSX. The Cursor help documentation describes this as a proxy — and it was in Cursor's own overlay, not Open VSX itself, that the tampered package appeared.

Anthropic's Felix Rieseberg clarified the scope on Hacker News: "A malicious actor used access to Cursor's marketplace to publish a tampered copy of the Claude Code extension, which we didn't build or publish. The versions on our official channels are not affected and this only impacts Cursor users."

Anthropic engineer Dworken separately confirmed on the Lobsters thread that version 2.1.313 was never published on OpenVSX, the VS Code Marketplace, or any of Anthropic's official hosts. Anthropic skipped to 2.1.314 to avoid confusion.

Lobsters commenter bakkot argued, based on Cursor's own documentation, that extensions cannot be uploaded directly to Cursor's VS Code extension marketplace by external parties — that Cursor itself proxies OpenVSX and manages its own additions. "I do not immediately see a way that something could be published on Cursor but not OpenVSX without it coming from Cursor themselves," bakkot wrote. Cursor's security notice states it "rotated our keys, rebuilt the marketplace, and brought it back online," but gives no public account of how the tampered package entered its pipeline under Anthropic's publisher name. That question remains open.

What the reviewed documentation shows about signing

The incident put a specific trust assumption on trial. A package labeled as Anthropic's in the Cursor store carries Cursor's assurance that the package it is serving is the one it received — but community commenters raised the concern that this guarantee rests on operational controls rather than cryptographic ones.

HN commenter AdrianCX put it directly: "Just did a quick search, OpenVSX has no extension signing?, no verifications?, what year is this... This could have been avoided by having extensions signed by company doing them with keys and review."

The Open VSX deployment documentation on GitHub describes the registry's architecture as built on PostgreSQL, Elasticsearch, and OAuth-based authentication. The reviewed passages of the README and deployment wiki do not mention artifact signing, cryptographic publisher verification, or reproducible-build requirements. The Eclipse project page describes Open VSX as a registry for managing and distributing extensions, with no reference to provenance controls in the captured documentation.

Cursor's help documentation, noted by HN commenter no-name-here, claimed the platform runs "automated malware and supply-chain analysis using commercial security tooling" and blocks extensions that fail review. That tooling did not catch the backdoor for eleven hours — and HN commenter jitbit pointed out the particular irony: the same documentation page contains a section titled "How Cursor reduces supply-chain risk."

In the sources reviewed, neither Anthropic nor Cursor announced plans to implement Sigstore, SLSA attestations, or mandatory publisher key signing for extensions distributed through Cursor's marketplace. Cursor's post-incident notice describes infrastructure hardening — key rotation and a marketplace rebuild — but does not describe a signing or provenance roadmap.

HN commenter tzone identified this as a shared-responsibility problem, not solely Cursor's: "Cursor Claude extension is marked as something made by Anthropic, so default assumption is that only people who can release that new extension would be a team at Anthropic. Since that is clearly not the case, that is just as much Anthropic's problem as it is Cursor's problem. There either needs to be a technical change so that extensions are signed with keys that Anthropic controls, or you should take the branding off from the Cursor extensions."

HN commenter ghshephard made the same point from the consumer perspective: "I was working on the clearly mistaken impression that 'Made by Anthropic' in the cursor store meant that the artifact had been signed by Anthropic."

The supply-chain tooling that exists — and where IDE ecosystems stand

The broader software supply chain has developed answers to exactly this problem:

Sigstore provides keyless, short-lived certificate signing tied to OIDC identity (typically a CI system or GitHub Actions workflow), with transparency logs that let third parties verify an artifact was signed during a legitimate build. It is the default signing mechanism for npm provenance attestations since 2023.

SLSA (Supply-chain Levels for Software Artifacts), a framework from Google and the OpenSSF, grades build and provenance security from no guarantees at level 0 up to hermetically isolated, reproducible builds at level 4.

in-toto provides a specification for supply chain integrity policies, where each step in a build pipeline produces a signed attestation that the final consumer can verify.

None of these appear in the reviewed Open VSX or Cursor documentation for VS Code extension distribution. The VS Code extension format is a .vsix file — a renamed zip — that contains no embedded signature or provenance metadata by default.

HN commenter ghshephard summarized the practical gap: "Cursor needs to add signing if they want to claim something was 'made' by another party. Anthropic needs to stamp out any provider from using said, 'Made by Anthropic' until they start adding signing to their process."

For developers assessing exposure today, HN commenter mrweasel identified the bind: "You could download the extension, diff it against the previous version and read all the code. Expecting people to do that is just a bit much. At some point we have to trust someone."

One practical control Cursor offers: team administrators can configure a delay before extension updates are applied — deferring installs until a marketplace version has been available for a minimum number of hours. At least one HN commenter said they intended to set this to 168 hours (one week) going forward. That is a friction-based mitigation, not a cryptographic one. Lobsters commenter Lazare noted the underlying situation plainly: "Cursor marketplace is a mirror of Open VSX except they inject some plugins that are not in Open VSX for some reason. This works because Open VSX has basically no security. Which was already an issue."

Indicators of compromise and remediation

For developers assessing their own exposure:

• The affected versions are Anthropic.claude-code 2.1.312 and 2.1.313, distributed through the Cursor VS Code Extension Marketplace on macOS and Windows between 2:27 a.m. and 1:35 p.m. PT on October 29, 2026
• The attacker's C2 server at 134.209.82[.]225 has been taken offline, but persistence mechanisms installed before that point continue to run independently
• The quickest check: grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found" (macOS/Linux)
• Full indicators of compromise — including VSIX SHA-256 hashes for both affected versions on darwin-arm64 and win32-x64, the svc-telemetry SSH key, LaunchAgent plist, and hidden shell scripts — are listed in Cursor's security notice at cursor.com/blog/claude-code-extension-security-notice
• Remediation scripts for macOS and Windows are available directly from Cursor
• Rotate any credentials accessible from affected machines using a separate, trusted device

The SHA-256 of the backdoored extension.js is ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15, per both Phorion's analysis and Cursor's notice.

What comes next

The 2024 XZ Utils backdoor was more sophisticated — a multi-year social engineering campaign targeting a critical compression library — but the structural lesson was the same: the build and distribution pipeline, not the application code, is the attack surface. Extensions are that pipeline for developer tooling.

The community push after XZ Utils produced tightened CI/CD review guidance and broader Sigstore adoption for container images. It did not produce signing requirements for VS Code extension distribution. This incident may create the pressure that argument alone did not.

Cursor, whose value proposition is a more capable developer environment, now has a direct reputational incentive to lead on extension signing. Open VSX, as the open-source foundation underneath multiple editor ecosystems, is the place where a shared signing standard would carry the most leverage. Whether either moves before a second incident makes the case again is the question the community will be watching.