Cursor Marketplace vs. Official Claude Code: What Version 2.1.313 Reveals

#ai #security #developers #supplychain

A developer sees the familiar Anthropic name and anthropic.claude-code identifier in an editor, clicks update, and gets malware. That is the uncomfortable lesson from a malicious Claude Code extension package that Cursor says was available in its marketplace for about eleven hours on October 29, 2026.

The distinction that matters is not simply “Claude Code was hacked” versus “Claude Code was not hacked.” Cursor identified one malicious package, version 2.1.313, in its VS Code extension marketplace. It says the build was not developed by Anthropic, and that it has no evidence that other versions or the official distribution were affected. The extension attempted to collect host details, add an SSH key, create persistence, and open a reverse tunnel. Cursor estimated that at most 5,000 users were affected.[1]

This is a comparison of distribution paths, not a claim that one editor or registry is universally safer. The same extension name can show up in multiple places, and the trust boundary changes with the place you installed it from.

What happened, and what did not

Cursor’s notice says the package was available from about 2:27 a.m. to 1:35 p.m. Pacific Time on October 29. It attempted to collect a machine’s hostname, username, operating system, architecture, home and working directories, configured Git email, public IP, and names of environment variables. It also tried to add an attacker-controlled key labeled svc-telemetry to authorized_keys, enable local SSH, and establish a persistent tunnel.[1]

There is an important qualification. Cursor says enabling the SSH service required administrator rights, so that part would fail on most macOS and Windows machines. That did not make the package harmless: it could still add the key, create persistence, and report host details. Cursor says the attacker server is now offline, but recommends remediation for anyone who installed the affected version from its marketplace during the exposure window.[1]

The first wave of reporting confused the distribution paths. Some early alerts attributed the malicious package to Open VSX. Cursor's own notice identifies its Cursor VS Code extension marketplace. Researchers later updated their reporting to reflect Cursor's clarification: the version was not found in Open VSX, Microsoft's Visual Studio Marketplace, or the npm package for Claude Code.[2] That correction matters. An extension identifier is not a cryptographic proof of where a particular package came from.

The comparison: editor marketplace vs. official distribution

Cursor’s extension marketplace. This was the affected path. If you installed or updated Anthropic.claude-code version 2.1.313 through Cursor's extension marketplace during the stated window, treat that machine as potentially compromised and follow Cursor's incident response instructions. Cursor removed the package, audited the marketplace, rotated keys, and says it found no evidence that other extensions were tampered with.[1]

Anthropic's official distribution. Cursor says it has no evidence that the official distribution or other extension versions were affected. Researchers checking the registries reported that version 2.1.313 was absent from Open VSX, the Microsoft Marketplace, and npm. That is useful scope information, not a blanket assurance that every channel is always safe. A malicious artifact could be isolated to one marketplace while another copy with the same publisher and version string remains clean.[1][2]

What this comparison does not prove. It does not prove how the malicious package entered Cursor's marketplace, who was responsible, or that any marketplace has a perfect review process. Cursor's notice documents response actions and scope, but does not explain the package's provenance. Don't turn an incident report into a story about a confirmed account takeover, compromised Anthropic build system, or a vulnerability in Claude Code itself. Those claims go beyond the public evidence cited here.

The practical winner is not “always use the CLI” or “never use Cursor.” It is the installation path you can identify and verify. A familiar name, verified publisher badge, and plausible version number are useful signals, but this incident shows they are not enough on their own.

Why the registry boundary matters

An extension listing is not one universal package. Editors can connect to different marketplaces and mirrors. A developer may think they installed “the Claude Code extension,” while the actual artifact came from a specific service with its own publishing and distribution path. The marketplace is part of the software supply chain, not just a search box.

Publisher identity and artifact integrity answer different questions. A trusted identity tells you something about who is allowed to publish under a namespace. It does not automatically prove that every file delivered through every downstream marketplace is the exact file built and released by that publisher. Investigations need to preserve both facts: the product name and version, and the store or download endpoint that delivered it.

Version numbers are evidence, but not the whole investigation. Version 2.1.313 was a useful indicator in this case. But incident response should also check when the update occurred, which editor and marketplace delivered it, and whether the payload left persistent files behind. Removing a visible extension can leave a separate launch agent, scheduled task, SSH key, or running process untouched. Cursor explicitly warns that uninstalling the extension may not be sufficient.[1]

If you may have installed 2.1.313

Start with the exact scope. Cursor's notice applies to installations from its marketplace between 2:27 a.m. and 1:35 p.m. PT on October 29, 2026. If your fleet uses Cursor, search endpoint and extension-installation telemetry for the extension ID, version, and install time. Do not rely only on today's installed version: an update may have replaced the visible package after the earlier version already ran.

Cursor's advisory includes platform-specific checks and cleanup scripts. On macOS and Windows, it says the key labeled svc-telemetry is an indicator. It provides commands to check the relevant authorized_keys locations, plus remediation scripts that remove the extension, known persistence mechanisms, running tunnel processes, and the unauthorized key.[1] Use the instructions directly from Cursor's notice rather than copying a shortened command from a social post.

If you find evidence of execution, treat it as an incident, not a routine extension reinstall. Cursor recommends isolating hosts showing evidence of payload execution or backdoor installation, removing persistence and tunnel processes, assessing whether to rebuild, and rotating credentials and sessions accessible from the affected machine from a trusted system.[1] An empty authorized_keys check alone cannot establish that nothing else ran.

For organizations, preserve logs and images before cleanup where incident-response policy requires it. Coordinate with your security team; don't run a remediation script as a substitute for evidence preservation or credential rotation. Cursor provides separate scripts and instructions for affected macOS and Windows systems in its notice.[1]

A repeatable extension supply-chain checklist

Before installing or updating a developer extension, keep this short checklist close:

Record the source. Note the editor, marketplace or registry, publisher, extension ID, version, and install time. “Installed Claude Code” is not enough detail for a later investigation.
Verify the exact channel. Open the extension's publisher page from the marketplace configured in your editor. Don't assume search results, mirrors, and vendor downloads are interchangeable.
Pin high-risk changes. For managed developer machines, consider controlling extensions through an allowlist or approved version policy instead of allowing every update immediately. Define an emergency update path so pinning does not become permanent neglect.
Monitor version changes. Alert on unexpected publisher, extension ID, version, or source changes. Keep installation logs long enough to investigate a version that was installed and later replaced.
Limit the extension host's reach. Run development tools with ordinary user privileges where practical. Restrict secrets and SSH credentials available to the workstation. Least privilege does not stop every malicious extension, but it reduces what a successful payload can reach.
Plan for cleanup beyond uninstall. Your response procedure should include persistence checks, process and network review, credential rotation, and rebuild decisions. The visible extension folder is only one possible artifact.
Write down a scope rule. For each incident, specify the exact package, registry, versions, and exposure window supported by evidence. Keep “not observed in this channel” separate from “impossible in this channel.”

This list applies beyond AI coding assistants. Editors increasingly host tools that can inspect repositories, invoke shells, read local configuration, and handle credentials. That makes the marketplace and extension runtime part of the developer workstation's security boundary.

Verdict

The October 29 incident is a case for channel-aware verification, not panic about every Claude Code installation. Cursor's report identifies a malicious package in its marketplace, with a bounded version and exposure window; it does not say the official Claude Code distribution was compromised. Researchers corrected early reports that pointed to Open VSX, underscoring why source attribution must be checked before repeating a headline.[1][2]

If you installed the affected package through Cursor during the specified window, follow the vendor's incident response steps and rotate credentials from a trusted device if the machine shows evidence of compromise. If you did not, still take the durable lesson: record where extensions come from, keep version and install history, and design for the possibility that removal alone will not undo execution.

I write about software engineering, developer tools, and AI every week. Subscribe if you want more practical breakdowns like this. Have you changed how your team approves editor extensions after a supply-chain incident? What control would have helped most?