Cursor's poisoned Claude Code extensions require endpoint cleanup as affected-version guidance expands

The October 31 correction broadens exposure checks

Developers who received Claude Code-branded extensions through Cursor need to investigate more than the initially identified release. Cursor's current notice identifies malicious Windows and macOS builds numbered 2.1.312 and 2.1.313, distributed on October 29 between approximately 09:27 and 20:35 UTC. The immediate concern is what those packages executed on developer machines, not simply whether the marketplace now supplies a clean replacement. [1][3]

Cursor updated its indicators and affected-version guidance on October 30 at 11:30 a.m. PDT. Phorion expanded its advisory on October 31 to include 2.1.312 after initially identifying only 2.1.313. Microsoft's technical investigation was published October 30. Together, these developments change the investigation scope for organizations that acted on the first alerts; they do not establish a new distribution event on October 31. [1][3][4]

The distribution channel matters more than the version label

StepSecurity corrected its earlier account implicating Open VSX. Its subsequent downloads found clean Open VSX builds of 2.1.312 and 2.1.314, and it verified that Cursor's replacement 2.1.312 artifact was clean. The resulting investigation rule is important: a version number alone cannot establish historical exposure. Investigators need the distribution channel and, where available, the actual package that was installed. Downloading a clean copy today does not establish what ran earlier. [5]

The evidence also does not establish an Anthropic infrastructure breach. Microsoft says the malicious packages were not distributed through Microsoft's Visual Studio Marketplace or the official Claude Code npm package. Anthropic told Microsoft its systems were not compromised. These distinctions keep the confirmed incident focused on the malicious artifacts served through Cursor rather than treating every Claude Code installation as affected. [1][3]

Ars Technica and WIRED reported Cursor's estimate that at most 5,000 users received the malicious extension. That figure is absent from the current Cursor notice supplied here and should remain an attributed distribution estimate. The two publications are repeating the same vendor estimate, not providing independent victim counts. Receipt of a package is also not proof that an attacker successfully logged into the recipient's machine. [1][6][7]

The SSH payload attempted persistence, but access could fail

Microsoft describes an injected loader that runs when the extension module loads. It attempts to install an attacker-controlled SSH key, enable SSH, establish an outbound reverse tunnel, configure persistence and report host information. Those behaviors explain why replacing the extension alone may leave security-relevant changes behind. Microsoft's analysis also limits one potential interpretation: the environment-variable collection sends variable names, not secret values, so that behavior alone does not demonstrate credential theft. [3]

Phorion found a failure condition on Macs: an unprivileged SSH-status check returns an error rather than the expected Off response, causing the malware to skip SSH enablement. A Mac with Remote Login already enabled presents a different risk, so failed enablement is not evidence that the machine is clean. The payload also contains Linux functionality, but Cursor's affected-build notice names Windows and macOS. Linux-capable code does not establish observed Linux infections. [1][4]

Customer telemetry extends the investigation beyond removal

Expel investigated four incidents across four customers, all involving Macs, and observed an outbound tunnel on a non-administrator's machine. In one case, the first observed malicious activity occurred at 04:45 UTC on October 30, approximately eight hours after Cursor's stated distribution window closed. Tunnel connections continued until 14:29 UTC. This is independent operational evidence of execution on customer endpoints, rather than another account repeating Cursor's marketplace notice. [1][2]

Expel says the late activity is consistent with an earlier download executing when Cursor next opened, but it did not establish the download time. It found no evidence that Cursor continued serving malicious builds after removal. The defensive implication is to investigate installation and execution times separately and hunt beyond the distribution window. An outbound tunnel connection, however, does not by itself establish successful attacker login or subsequent access to files. [2]

Preserve evidence, then remove endpoint persistence

Exposure checks should cover historical Cursor installations of both affected versions, including automatic updates. Preserve available extension packages and relevant endpoint telemetry before cleanup so investigators can distinguish a malicious historical artifact from a clean replacement bearing the same version number. Where execution is confirmed, isolate the endpoint and collect SSH authorization files and persistence artifacts. Absence of the svc-telemetry marker alone does not establish that a machine was unaffected. [1][3][5]

Corroborating indicators include the server 134.209.82[.]225, the SSH-key comment svc-telemetry, the macOS LaunchAgent com.apple.sysmond.plist and Unix files .smt and .smtk. On Windows, investigators should examine the SysMon task and Startup-folder sysmon.cmd. These indicators need context: a matching or similar name should prompt validation, not automatic deletion of a potentially legitimate object. They are evidence to combine with package provenance, process activity and network observations. [3][4]

Cursor recommends removing unauthorized keys, persistence mechanisms and tunnel processes, assessing whether a rebuild is necessary, and rotating accessible credentials and sessions from a trusted system. Those actions address possible access that replacing the extension cannot undo. Credential rotation is a precaution in the response guidance, not proof that secrets were stolen. Microsoft's distinction between environment-variable names and values remains relevant when describing what the available evidence actually confirms. [1]

The publishing compromise and successful-access totals remain unresolved

Cursor says it removed the malicious builds, audited its marketplace, rotated keys, rebuilt the service and worked with the hosting provider to disable the attacker's server. Those are distribution and infrastructure containment measures. They do not establish that every affected endpoint has been cleaned. Neither the technical analyses nor the reported receipt estimate supplies a verified total of machines successfully accessed by attackers. [1][2][3][6]

How the attacker obtained the ability to publish or substitute the builds remains unexplained. WIRED sought an explanation from Cursor without receiving one, and Ars also reported unanswered questions about the distribution compromise. The next useful developments would be a documented entry mechanism, further artifact or version corrections, and evidence distinguishing attempted tunnels from completed attacker sessions. That is an editorial assessment of the remaining gaps, not a prediction of additional compromise. [4][5][6][7]