Cursor says maliciously modified copies of the Claude Code extension were distributed through its extension marketplace on October 29, 2026. Its current security notice identifies versions 2.1.312 and 2.1.313 for macOS and Windows, broadening the version scope described in initial reporting. (cursor.com)
The reported exposure estimate is at most 5,000 users, according to Cursor statements cited by Ars Technica and BankInfoSecurity. That is an upper bound on potentially affected users—not evidence that attackers successfully gained remote access to 5,000 machines. The notice inspected for this article does not itself include that figure. (arstechnica.com)
The availability window ran from approximately 2:27 a.m. to 1:35 p.m. Pacific Time on October 29, or 09:27–20:35 UTC. Developers and security teams therefore need to consider the installation’s distribution channel and timing, as well as its version number, when assessing possible exposure. (cursor.com)
Which installations are implicated
The distinction between marketplaces matters. StepSecurity says it verified that the 2.1.312 package obtained from Open VSX was clean, despite sharing a version number with a malicious package identified in Cursor’s marketplace. Its updated research also corrects an earlier account that had incorrectly described Open VSX as the origin of the malicious release. (stepsecurity.io)
In a public Hacker News comment, an account identifying itself as Dworken from Anthropic said version 2.1.313 had never been published on Open VSX, Microsoft’s VS Code marketplace or Anthropic’s official hosts. The comment said an attacker published a fake version through Cursor’s marketplace and that Anthropic numbered its next update 2.1.314 to avoid confusion. (news.ycombinator.com)
BankInfoSecurity separately reported Anthropic’s statement that it did not build, publish or host the tampered extension. These accounts describe a compromised extension-distribution channel; they do not establish a compromise of the Claude model. How the attacker obtained access remains unexplained in the reporting reviewed. (bankinfosecurity.com)
Cursor’s remediation guidance
Cursor advises checking endpoint, network and extension-installation records for evidence of the malicious package. Machines showing payload execution or backdoor installation should be isolated. Its guidance calls for removing unauthorized SSH keys, persistence mechanisms and running tunnel processes, assessing whether rebuilding is necessary, and rotating accessible credentials and sessions from a trusted system. (cursor.com)
An extension update is not equivalent to cleaning an affected computer. StepSecurity’s analysis describes persistence that survives removal of the extension itself. Consequently, the presence of a newer extension version does not, on its own, establish that earlier malicious changes have been removed from the machine. (stepsecurity.io)
Cursor says it removed the malicious packages, stopped distribution, shut down and rebuilt the marketplace, and rotated its keys. It also says its audit found no other tampered extensions and that the attacker’s server was taken offline with the hosting provider’s assistance. Those are containment measures, not confirmation that exposed endpoints have been cleaned. (cursor.com)
What researchers observed
StepSecurity reports that its sandbox analysis found a loader that planted an attacker-controlled SSH key, installed persistence, opened a reverse SSH tunnel and transmitted host reconnaissance information. These are laboratory observations about the malicious package’s behavior, rather than a tally of successful intrusions into developers’ computers. (stepsecurity.io)
Phorion, whose original research is linked in the Ars report, describes an important limitation: flaws in the malware’s attempt to enable SSH could prevent remote access on a Mac without SSH already running. Nevertheless, its analysis found that the unauthorized key and persistence could still be installed and host information reported. (phorion.io)
That distinction cuts both ways. A failed remote-access step does not make the installation harmless, but the presence of malicious code does not prove an attacker subsequently logged in or stole source code. The available research supports investigating affected systems without treating every possible exposure as a confirmed downstream breach. (phorion.io)
A wider developer-tool security risk
A separate incident earlier this year illustrates why extension compromises attract enterprise attention. In its May 20 disclosure, GitHub said it detected and contained an employee-device compromise involving a poisoned third-party VS Code extension on May 18. Its investigation found exfiltration of internal repositories; the company said it isolated the endpoint and rotated critical secrets. (github.blog)
That incident is context, not evidence of similar losses here. It demonstrates the potential organizational consequences of malicious developer tooling, while the Cursor case still requires separating package availability, execution and subsequent attacker activity. For engineering leaders, the immediate question is which machines received the affected builds and what evidence those machines retain—not simply whether the marketplace has reopened. (github.blog)
