Signed by the Right Publisher: Trojanized Claude Code on Cursor’s Marketplace

Key Takeaways

On October 29, 2026, a tampered build of Anthropic’s Claude Code extension was served through Cursor’s extension marketplace. It appeared under the legitimate identifier anthropic.claude-code, not under a typosquatted or look-alike name. Cursor reports that malicious builds of versions 2.1.312 and 2.1.313 for macOS (darwin-arm64) and Windows (win32-x64) were available from about 2:27 a.m. to 1:35 p.m. Pacific Time. Cursor states that Anthropic did not develop these builds [1]. Cursor initially said that at most 5,000 users were affected, although its revised notice no longer gives a user count [5][6]. Anthropic has stated that the incident did not involve a compromise of its systems or employee laptops, and that the versions on its official channels, including Open VSX and the Microsoft Visual Studio Marketplace, were not affected [2][7].

The payload was a loader placed at the start of the extension’s extension.js bundle. It ran when the extension loaded, with no user interaction required [4][5]. It planted an attacker SSH key labeled svc-telemetry, tried to enable the local SSH service, and opened a reverse SSH tunnel to 134.209.82[.]225. It also installed persistence on each operating system and sent host reconnaissance to the attacker over plain HTTP [1][2]. Uninstalling or updating the extension does not remove the planted key or the persistence mechanisms [1][3].

The central lesson is about where trust is placed. Every signal a developer or administrator normally relies on looked correct: the extension ID, the publisher name, the version sequence, and the fact that it came from the editor’s built-in marketplace. The compromise happened in the distribution layer that sits between the real publisher and the user. Publisher-identity controls are not designed to detect that kind of failure. As of this writing, neither Cursor nor Anthropic has publicly explained how the attacker obtained the ability to publish under that identifier on Cursor’s marketplace [5][6][7].

Organizations that ran Cursor during the exposure window should treat any host with the svc-telemetry key or the listed persistence artifacts as compromised. They should rotate every credential reachable from that host, doing so from a known-clean machine [1][2]. For the longer term, organizations should apply install cooldowns, extension allowlists, and provenance checks to the IDE extension tier, the same controls they already expect for package registries.

Background

Cursor is a commercial AI-first code editor built on the Visual Studio Code codebase. Like other VS Code forks, it cannot use Microsoft’s Visual Studio Marketplace. Instead, it relies on the Open VSX registry for third-party extensions. Cursor’s documentation describes routing extension search and downloads through its own marketplace proxy rather than passing them straight to Open VSX. It also states that Cursor runs automated malware and supply-chain analysis on extensions using commercial security tooling [10]. Cursor operates a separate publisher-verification process. A Cursor staff member has confirmed on the company forum that Open VSX verifications are not passed through, because Cursor performs its own verification [11]. Cursor’s marketplace is therefore a distinct distribution point with its own trust decisions, not a transparent mirror. This architectural detail explains why the tampered build reached Cursor users but not users of other registries.

Claude Code is Anthropic’s agentic coding tool. Its IDE extension, published as anthropic.claude-code, is a widely used AI assistant extension in the VS Code ecosystem. An AI coding extension typically runs with the developer’s full user privileges. It can read source trees, spawn processes, and reach environment variables that often hold cloud, source control, and package registry credentials. A compromised build of such an extension gains code execution in one of the most credential-dense environments in many organizations. CSA’s earlier research on GlassWorm and related campaigns identified the developer workstation as a primary supply chain target for this reason [13].

The incident timeline is now well established across the vendor notice and independent analyses, which agree on the core facts. Early reports, however, placed the compromise on Open VSX. The Hacker News, StepSecurity, and OpenSourceMalware each later corrected their coverage after Cursor and Anthropic clarified that Cursor’s marketplace was the only distribution point [2][4][6]. StepSecurity independently checked the Open VSX registry. It confirmed that the 2.1.312 build there is clean and that Open VSX returns “not found” for 2.1.313 [2]. That correction matters for how defenders scope their response, as the timeline below shows.

Security Analysis

Distribution-layer compromise under a legitimate identity

The incident differs from the GlassWorm-era campaigns of 2025 and 2026 because of what the attacker did not need to do. Those campaigns relied on trojanized extensions and on malicious versions published with stolen registry tokens [13]. Here, the malicious package carried Anthropic’s real extension ID and publisher identity, as The Hacker News reported [6]. The version number also followed the expected sequence. Phorion’s co-founder told Ars Technica, as reported by The Next Web, that the malicious 2.1.313 was posted to the official Anthropic account, “effectively superseding 2.1.312” [7]. Because Cursor extensions update automatically by default, users with auto-update enabled could have received the build without taking any action [6][7].

The title of this note refers to the build being “signed by the right publisher.” That is meant figuratively: every identity signal the user could see pointed to Anthropic. The public record does not yet say whether the build carried a cryptographic signature, or whose key would have produced it. The Hacker News and The Next Web both report that the method used to introduce the unauthorized update remains unclear [6][7], and the public record likewise does not explain how the tampered build passed marketplace checks or how it was signed. That gap prevents a definitive control analysis. Even so, the confirmed facts support a strong working inference. Version 2.1.313 never existed on Anthropic’s official channels, yet it was served to users under Anthropic’s identity [2][7]. Whoever introduced it was able to publish to Cursor’s distribution layer under Anthropic’s identifier, whether through access to the marketplace itself, a feeding pipeline, or a publishing credential. The exact path has not been disclosed.

This points to a structural weakness in how many organizations reason about extension trust. Verified-publisher badges confirm who registered an identifier. Cursor’s own documentation describes verification as confirming publisher identity and calls it “one layer of trust” [10]. Neither the badge nor the extension ID says anything about whether the bytes being delivered match what that publisher actually released. When the marketplace itself is the point of compromise, controls anchored on publisher identity can be bypassed entirely. Cursor’s automated malware analysis also did not stop the build during the roughly 11-hour window. This suggests that a loader appended to a large, legitimate, obfuscated bundle can evade scanning tuned for wholly malicious packages. The malicious extension.js was about 3.7 MB, only about 7 KB larger than the prior clean release [2]. Alternatively, depending on the undisclosed entry vector, the build may have bypassed the scanning pipeline entirely.

Payload behavior and its limits

Analyses by Cursor, StepSecurity, OpenSourceMalware, and Phorion (as cited by Sophos) agree on the payload’s design [1][2][3][4]. The loader runs under plain Node.js and does not use VS Code APIs. Loading the extension module is enough to trigger it, whether that happens at editor startup or when the extension’s webview opens. No Claude conversation and no package-manager lifecycle hook are needed [2][4]. It suppresses most of its own errors so that the legitimate extension continues to work normally [4]. Each stage of the payload maps to a well-understood MITRE ATT&CK technique, as summarized below. The technique mappings are CSA’s assessment; the stage descriptions come from the cited analyses.

Several factors limited the realized impact, and defenders should weigh them carefully rather than treat them as reassurance. Enabling SSH requires administrator rights, which the extension generally lacks on macOS and Windows. Cursor and Phorion both report that this step likely failed on most such hosts [1][5]. However, the key was still added, persistence was still installed, and host details were still sent regardless [1]. The loader also contains Linux persistence logic (a cron @reboot entry), although no Linux build has been reported as distributed [1]. On a macOS host with Remote Login already enabled, the planted key alone may have provided interactive access. The beacon sent only the names of environment variables, not their values. As researcher Paul McCarty observed, though, those names show an operator which cloud providers and credential types are present, which makes them useful for choosing targets [6]. The attacker server has since been taken offline [1]. Researchers have not observed any follow-on payloads [4][6]. Investigators have not publicly established whether any tunnel sessions were used during the exposure window [9].

Why AI coding extensions raise the stakes

Seen from the endpoint, this payload is a conventional backdoor. What raises its significance is the host it targeted. AI coding extensions are installed widely and quickly, are updated often, and are routinely granted broad local authority because that authority is what makes them useful. CSA’s research note on AI coding agents argued that these tools have become a supply chain node that existing provenance and access models do not yet audit [12]. This incident extends that argument from the agent’s outputs to the agent’s own distribution channel. The tool that organizations expect to write and review code was itself the delivery vehicle. Fork-based editors widen the exposure further. Each fork that runs its own marketplace or proxy adds another distribution point that can serve a different binary under the same publisher identity. Cursor’s documentation warns that the same extension ID can resolve to different publishers or code on Open VSX than on the Microsoft Marketplace [10].

Recommendations

Immediate Actions

Every organization with Cursor users should first determine its exposure. The key question is whether any host installed or updated anthropic.claude-code from Cursor’s marketplace between roughly 09:27 and 20:35 UTC on October 29, 2026. A version number alone does not prove compromise, because a genuine 2.1.312 also exists on other registries [9]. Responders should instead check each host for the specific artifacts from Cursor’s notice and StepSecurity’s analysis, summarized in the table below [1][2]. Any single match warrants treating the host as compromised.

Where indicators are found, responders should preserve evidence before cleaning anything. They should isolate the host and then remove the key, persistence, and tunnel processes. Cursor’s remediate-macos.sh and remediate-windows.ps1 scripts automate removal and exit with a non-zero status if anything remains [1]. Responders should then rotate all credentials reachable from the host, from a trusted machine. That includes source control, CI/CD, cloud, SSH, and package registry tokens [1][2]. StepSecurity recommends rebuilding rather than cleaning any host whose tunnel is known to have connected [2]. BleepingComputer’s reporting likewise advises invalidating active sessions and restoring from safe backups [5]. Finally, once remediation or rebuild is complete, every affected host should be updated to 2.1.314 or later. The update is not itself a remediation step, since updating the extension does not remove the planted key or persistence [1][3].

Short-Term Mitigations

The 11-hour exposure window points to a simple control that may have limited exposure. Cursor offers a team-level install cooldown that defers extension installs and updates until a version has been public for a minimum number of hours. It is disabled by default [10]. Had a cooldown longer than the exposure window been in place, it would likely have kept hosts from receiving this build, because Cursor pulled it before the build reached that age. That conclusion is an inference from the timeline, not a tested result, and it assumes the cooldown measures the age of the specific artifact served. The tampered build also appeared as 2.1.312, a version number first published on October 27. If version age is keyed to the version number or to marketplace metadata, a cooldown may not have blocked that variant, so organizations should confirm with Cursor how artifact age is determined. With that caveat, organizations should set a cooldown for AI coding extensions in particular; CSA suggests 24 to 72 hours as a starting range, longer than the 11-hour window observed here. They can accept that delay for routine updates while keeping an expedited path for security fixes.

Allowlisting is a complementary control. Cursor supports restricting installs to approved publishers or extension IDs through its team dashboard or MDM (AllowedExtensions) [10]. Allowlisting would not have blocked this specific build, because the extension ID was legitimate. It does, however, shrink the population of extensions that can serve as a vehicle for such an attack, and it simplifies inventory and incident scoping. Enterprise teams should also evaluate Cursor’s option to require valid Open VSX signatures before install [10]. Version 2.1.313 was never published to Open VSX, so this setting may have blocked it if it validates against Open VSX’s own repository signature. Neither vendor has confirmed that, however, and organizations should test the setting’s behavior rather than assume it. Cursor itself describes signature verification and cooldowns as client-side controls that complement marketplace-layer analysis but do not replace it [10].

Detection engineering should also catch up with this attack pattern. Writes to authorized_keys by an editor or Node.js process, and new LaunchAgents or scheduled tasks created by an IDE process, are rare in normal developer activity and are strong alerting candidates. Outbound SSH to unfamiliar hosts is also worth monitoring. Because developers use SSH routinely for Git and remote access, however, that signal needs a baseline of expected destinations, with particular attention to reverse-forwarding (-R) invocations.

Strategic Considerations

Over the longer term, organizations should treat IDE extensions, and AI coding extensions in particular, as software supply chain dependencies. That means applying the same expectations used for container images and language packages. Those expectations include an inventory of what is installed and where, a defined set of approved distribution sources, and ideally verification that the delivered artifact matches what the publisher actually released. That last requirement is the gap this incident exposed. The ecosystem needs publisher-anchored provenance for extensions: publisher-held signatures or attestations that a fork marketplace cannot forge, verified by the client independently of the marketplace serving the bytes. Repository-level signing alone proves only that the bytes came from a particular marketplace. Organizations evaluating AI-first editors should ask vendors directly how their marketplace verifies that a new version came from the upstream publisher, who holds write access to the distribution layer, and how quickly tampering would be detected.

Organizations should also limit what any single extension can reach. Keeping long-lived cloud and registry credentials out of developer environment variables reduces the value of compromising one IDE. Short-lived, brokered credentials help, as do separated development environments such as dev containers or remote workspaces. Finally, procurement and vendor-risk teams should add distribution-channel security to their due diligence for developer tooling vendors. Based on both vendors’ statements so far, this incident illustrates how a supplier’s own channels can remain unaffected while a downstream redistributor serves tampered builds under the supplier’s identity.

CSA Resource Alignment

CSA’s research note AI Coding Agents: An Unaudited Supply Chain Node [12] is the most direct precedent for this incident. It argued that AI coding tools act inside the software supply chain in ways that existing provenance and access models were not built to audit. It recommended extending SBOM, provenance, and lineage practices to cover them, and it mapped those risks primarily to the Threat & Vulnerability Management (TVM) and Application & Interface Security (AIS) domains of AICM v1.1, alongside governance controls. The Cursor incident supports that argument from a different angle. The unaudited element here was not code the agent produced but the agent’s own delivery path, which shows that provenance for AI coding tools has to cover both what they emit and how they arrive.

CSA’s GlassWorm research note [13] documented the 2025–2026 campaigns that abused Open VSX and other registries. It established that a single compromised developer workstation can expose source code, cloud credentials, and CI/CD tokens. The reconnaissance in this payload, which captured Git identity and the names of credential-bearing environment variables, fits that pattern closely. GlassWorm relied on trojanized extensions and stolen publishing tokens. This incident shows the same objective reached through a distribution intermediary, which suggests that defenses focused on publisher reputation alone are insufficient. Earlier CSA analysis of the AI developer toolchain observed that VS Code forks pulling from Open VSX inherit the extension attack surface without inheriting all of the Microsoft Marketplace’s controls, and that auto-update speeds up the spread of a compromised version.

CSA’s research note AI Toolchain Hijacked: IDE Plugin API Key Theft [17] provides the closest precedent at the marketplace layer. It examined the JetBrains fake AI assistant campaign, GlassWorm, and the May 2026 compromise of the legitimate Nx Console extension, in which a tampered version of a widely trusted extension was live for about eighteen minutes yet still compromised a high-profile victim. That note concluded that marketplace review has not kept pace with these threats and urged marketplace operators to treat compromise of existing publisher identities as a design assumption rather than an edge case. The Cursor incident is a further instance of that pattern, with the added twist that the compromised layer was a fork’s own marketplace rather than the upstream registry.

The CSA AI Controls Matrix (AICM) v1.1 [14] gives organizations a framework for putting these recommendations into practice. The Supply Chain Management, Transparency, and Accountability (STA) domain covers the vendor and redistributor due diligence described above. The Threat & Vulnerability Management (TVM) and Application & Interface Security (AIS) domains cover extension inventory, cooldown policy, and integrity verification. The Identity & Access Management (IAM) domain covers reducing standing credentials on developer endpoints. Organizations that assess AI tooling vendors through STAR for AI can use these AICM controls to ask concrete questions about marketplace integrity and publisher provenance.

References

[1] Cursor. “Security notice — malicious version of Anthropic.claude-code (2.1.312 and 2.1.313) identified in the Cursor VS Code Extension Marketplace.” Cursor Blog, October 29, 2026 (updated October 30, 2026).

[2] StepSecurity. “Trojanized Claude Code Extension Delivered Persistent SSH Backdoor to Developer Machines.” StepSecurity Blog, October 30, 2026.

[3] Sophos X-Ops. “Malicious Claude Code extension distributed through Cursor marketplace.” Sophos Blog, October 2026 (undated; accessed October 31, 2026).

[4] OpenSourceMalware. “Trojanized Claude Code Extension Plants an SSH Backdoor.” OpenSourceMalware, October 30, 2026.

[5] Toulas, Bill. “Malicious Claude Code extension on Cursor planted SSH backdoors.” BleepingComputer, October 30, 2026.

[6] Lakshmanan, Ravie. “Official Claude Code Extension on Cursor Marketplace Trojanized with Persistent SSH Backdoor.” The Hacker News, October 30, 2026.

[7] Constantin, Ana Maria. “Anthropic denies breach as tampered Claude Code extension hits Cursor users.” The Next Web, October 31, 2026.

[8] Zadok, Nir. “Compromised Claude Code Extension (2.1.313) in Cursor Marketplace Plants Attacker SSH Key and Persistence.” OX Security, October 30, 2026.

[9] Rescana. “Trojanized Claude Code Extension 2.1.313 in Cursor Marketplace Plants SSH Backdoor.” Rescana, October 30, 2026 (updated October 31, 2026).

[10] Cursor. “Extensions.” Cursor Documentation, accessed October 31, 2026.

[11] Cursor Community Forum. “Extension publisher verified on OpenVSX not showing as such in Cursor.” Cursor Forum, accessed October 31, 2026.

[12] Cloud Security Alliance AI Safety Initiative. “AI Coding Agents: An Unaudited Supply Chain Node.” CSA Labs, July 8, 2026.

[13] Cloud Security Alliance. “GlassWorm Takedown: Developer Supply Chain Attack Campaigns.” CSA Labs, May 28, 2026.

[14] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.

[15] MITRE. “Supply Chain Compromise: Compromise Software Supply Chain (T1195.002).” MITRE ATT&CK, accessed October 31, 2026.

[16] MITRE. “Account Manipulation: SSH Authorized Keys (T1098.004).” MITRE ATT&CK, accessed October 31, 2026.

[17] Cloud Security Alliance AI Safety Initiative. “AI Toolchain Hijacked: IDE Plugin API Key Theft.” CSA Labs, June 2026.