--- title: Trojanized Claude Code Extension v2.1.313 Targets Cursor Developers - Capstone Technologies Group description: A trojanized Claude Code v2.1.313 extension hit up to 5,000 Cursor users on October 29, stealing system metadata and attempting SSH backdoors. Steps to respond. canonical_url: https://captechgroup.com/threat-intelligence-center/trojanized-claude-code-extension-v21313-targets-cu-e8bbee language: en-GB date: 2026-10-31T12:34:31Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/trojanized-claude-code-extension-v21313-targets-cu-e8bbee. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 4803 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/trojanized-claude-code-extension-v21313-targets-cu-e8bbee. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. For 11 hours on October 29, developers who installed or updated Anthropic's Claude Code extension inside the **Cursor** integrated development environment (IDE) received a **malicious version 2.1.313** in place of the legitimate release. According to Cursor's disclosure, the tampered build was live in its extension marketplace from 9:27 a.m. to 8:35 p.m. GMT, and the company says at most 5,000 users were affected. Cursor states the malicious version was not developed by Anthropic and that it will contact affected users directly. Original reporting for this article comes from [Dark Reading](https://www.darkreading.com/cyberattacks-data-breaches/devs-trojanized-claude-code-extension-cursor "Source: Dark Reading"). The attacker did not build a lookalike listing. Instead, the official extension was hijacked and swapped for a copy that kept all of the real code and added a 66-line loader to its `extension.js` file, per analysis from the community threat intelligence platform OpenSourceMalware. Because Cursor delivers extensions through its own marketplace, one tampered listing reached every developer who pulled an update during that window. The code ran as soon as the extension loaded, with no Claude conversation required. Coding tool extensions carry more risk than the browser add-ons most people picture. "IDE extensions are scarier than browser extensions because, unlike browser extensions, they are designed to have the same level of permissions as their host," Gal Weizman, security researcher at Forever Security, told Dark Reading. In practice, an extension can run code, read files, and send network requests with the same access as the developer who installed it. That matters for your business because developer workstations typically hold source code, cloud credentials, API keys, and access paths into production systems. Version 2.1.313 collected identifying data from infected machines and, in a minority of cases, could have given attackers persistent, privileged access. Public details are still limited. Cursor has not said how the attacker gained the ability to publish the altered version, and no group has been named as responsible. If your engineering team uses Cursor with Claude Code installed, you should establish whether any machine updated the extension on October 29. ## How the Trojanized Claude Code v2.1.313 Package Works The attacker did not build a lookalike package. According to an analysis by the community threat intelligence platform **OpenSourceMalware**, the trojanized build kept the real extension's name, branding, publisher identity and legitimate code intact. The only change was a **66-line loader** added on top of the existing `extension.js` file. Because the listing was the genuine one, developers had nothing visual to compare against. The package looked exactly like the tool they already trusted. Version **2.1.313** arrived through the normal update channel as the newest release. Editors that auto-update extensions pull the highest published version without asking. Users who updated manually saw a routine version bump on an official listing. The source does not say whether the attacker chose this version string for a specific reason. Any version newer than the last legitimate release would have been enough to push the payload to installed copies. IDE extensions run inside the editor's extension host with the same rights as the user who launched the editor. Forever Security researcher Gal Weizman described the difference from browser add-ons this way: > "IDE extensions are scarier than browser extensions because, unlike browser extensions, they are designed to have the same level of permissions as their host. They can run code, access the filesystem, fire network requests and more." In practice, that means an extension can read files in the home directory, see environment variables, spawn shell processes and open outbound connections. A developer workstation usually holds source code, Git configuration and SSH material, so this access reaches the same assets your build and deployment pipeline depends on. Extensions declare **activation events**, which are the conditions that tell the editor when to load them (opening a workspace, running a command, or simply starting up). The malicious loader executed as soon as the extension loaded. The user did not need to open a Claude conversation or interact with the tool at all. Installing or updating it in Cursor was enough to trigger the code. The source describes the payload in specific terms. It maps to the following behaviors and MITRE ATT&CK techniques: - **Supply chain compromise (T1195.002):** malicious code inserted into an official, trusted package. - **SSH key implant (T1098.004):** the loader tries to add an attacker-controlled key to the victim's SSH configuration. - **Reverse tunneling (T1572):** the added key is meant to support reverse tunnels that give the attacker a backdoor into the machine. - **Persistence on macOS (T1543.001):** a LaunchAgent registered as a background process. - **Persistence on Windows (T1053.005, T1547.001):** scheduled tasks running with system privileges, plus a fallback Startup script. - **Host discovery and exfiltration (T1082, T1033):** separate web requests send collected system details to the attacker. The backdoor path had a built-in limit. Cursor stated that turning on the local SSH service requires administrative privileges, which the extension holds only in "highly unusual circumstances." For most victims the remote access chain would have failed. A minority could have given the attacker persistent, privileged access. The data theft did not depend on admin rights. Stolen fields were limited to hostnames, usernames, operating systems, OS architectures, home directory paths, environment variable names, working directories, configured Git emails and public IP addresses. The source lists environment variable *names* only, with no mention of their values. This set still maps a developer's identity, machine and project layout, which supports targeted follow-up [phishing](https://attack.mitre.org/techniques/T1566/ "MITRE ATT&CK: T1566") or repository attacks against your engineering staff. Published indicators are thin. The source confirms the malicious version string `2.1.313` and the modified `extension.js` file. It does not list file hashes, attacker domains, IP addresses or the attacker-controlled SSH key. Cursor says it worked with the cloud hosting provider to take the malicious infrastructure offline, but the infrastructure details were not disclosed. This incident follows a broader pattern of malicious and hijacked packages in VS Code-compatible extension ecosystems, including registries such as Open VSX that serve forked editors. In those marketplaces, a single stolen publishing credential lets an attacker ship code to every installed copy of an extension through its normal update channel. ## What a Compromised Developer Workstation Exposes Cursor's disclosure lists exactly what the malicious build sent out: hostnames, usernames, operating systems and their architectures, home directory paths, environment variable names, working directories, configured Git emails, and public IP addresses. No single item on that list is a password. Taken together, they tell an attacker who your developer is, which machine they use, where it sits on the internet, and which projects they work on. Environment variable names matter more than they first appear. The code collected the names of those variables, and the source does not say it took their values. A list of names still shows which cloud providers, AI services, and internal tools a developer has configured. That gives an attacker a shopping list for a follow-up intrusion or a convincing phishing message aimed at your engineers. Working directory and home directory paths often contain project names, client names, or repository names. Git email addresses connect a real person to your code repositories. If your team builds software for clients, this metadata can reveal who your customers are and what you are building for them. The larger exposure sits in the minority of cases where the SSH backdoor could have worked. Cursor notes that this required administrative privileges, which the extension holds only in highly unusual circumstances. Where it did succeed, the attacker would have persistent, privileged access to the workstation. Forever Security researcher Gal Weizman points out that IDE extensions run with the same permissions as their host, so they can run code, read the filesystem, and send network requests. A typical developer machine holds far more than its owner's own files. Depending on how your team works, a compromised workstation could expose: - **Source code and intellectual property**, including unreleased features and proprietary logic - **`.env` files** containing database passwords and service credentials - **SSH keys** that open servers and code repositories - **Cloud CLI credentials** that can create, change, or delete cloud resources in your account - **Git tokens** that allow pushing code to your repositories - **AI service API keys**, including Anthropic keys, which an attacker can use to run workloads billed to your account Those credentials can lead well beyond one laptop. A Git token or cloud key may reach your CI/CD pipelines (the automated systems that build, test, and ship your code), your package registry accounts, or production environments. An attacker with publishing rights can push a tampered release to your own customers. Weizman notes that the most common way extensions and plug-ins get hijacked historically is theft of locally stored publishing credentials, which is the same pattern a stolen developer token would enable against your software. For a business, this turns one infected workstation into a possible supply chain problem. If an attacker uses your credentials to alter software you distribute, your customers inherit the compromise. That can trigger incident investigations on their side, security reviews of your vendor relationship, and claims that you fell short of contractual security commitments. The compliance side follows the data. If a developer machine held customer records, production database credentials, or keys to systems that store personal information, unauthorized access may create breach notification duties under the laws and contracts that apply to you. Usernames, email addresses, and IP addresses can also count as personal information under some privacy regimes, which puts even the confirmed metadata theft within scope for legal assessment. The confirmed theft in this incident is limited to system metadata, and the deeper credential exposure applies only to the small set of machines where the backdoor could run with elevated rights. ## Checking Cursor Installations and Responding to Exposure Your first task is to confirm whether any developer workstation in your organization ran Claude Code version 2.1.313 inside Cursor. On each Cursor installation, open the Extensions panel or list the contents of `~/.cursor/extensions`, then record the Claude Code version and publisher name. Treat any copy at 2.1.313, or any Claude Code listing from a publisher other than Anthropic, as compromised. Uninstall the extension on those machines and disconnect them from the network until they have been checked. Removing the extension leaves behind anything the loader already set up, so the cleanup has to include its persistence mechanisms. Hunt on each affected machine for the specific changes the malicious build attempted: - Unrecognized public keys added to the user's SSH configuration, and a local SSH service that has been switched on without a known reason. - New **LaunchAgents** on macOS that start background processes at login. - **Scheduled tasks running with SYSTEM privileges** on Windows, plus unfamiliar scripts in the user's Startup folder. - Outbound SSH sessions or reverse tunnels to hosts your team does not operate. Cursor stated that enabling the SSH service requires administrative rights, which the extension holds only in unusual cases. Start with developers who run with local admin rights, since those are the machines where the backdoor had a real chance of working. Next, rotate every secret reachable from an affected workstation. That includes Git tokens, SSH keys, cloud credentials, API keys (Anthropic keys among them), and CI/CD or package registry tokens. The disclosed data covered environment variable names, and a machine with a working backdoor exposes the values as well. A stolen registry or CI/CD token lets an attacker publish code under your company's name, which is how this incident started. After rotation, review recent Git pushes, cloud audit logs, and API usage dashboards for activity that does not match your developers' normal work. Look for commits outside working hours, new access keys, and API spending from unfamiliar IP addresses. Over the following days, update Cursor on every machine. Forever Security's research found that Cursor's built-in browser could be tricked into running arbitrary code after the agent turned off its own safety sandbox. Cursor patched that issue on Oct. 1, so installs older than that build still carry the flaw. Confirm with your developers how they obtain Claude Code, and require that any editor integration list Anthropic as the verified publisher. Tell your developers what happened and what to expect. Cursor says it will contact affected users directly, so ask staff to forward those notices to your security team. Remind them that the stolen usernames, hostnames, and Git emails give an attacker enough detail to write convincing follow-up messages. For the longer term, put these controls in place: - **Extension allowlists** or approved-publisher policies for Cursor and other VS Code-based editors, with automatic extension updates reviewed before wide rollout. - A **secrets manager** so tokens and keys stay out of plaintext files and shell profiles on developer laptops. - **Endpoint detection and response (EDR)** on developer machines, with alerts for new scheduled tasks, LaunchAgents, and changes to SSH keys. - AI coding tools added to your software approval process, including a review of which agent features can change sandbox or permission settings. If your team publishes its own extensions or packages, follow Weizman's advice and require two-factor authentication for publishing. He notes that extension hijacks most often begin with stolen locally stored publishing credentials, and a single access token is the only barrier in many publishing setups. Enable 2FA on every account that can push a new version of your software. ## Treat AI Coding Extensions as Privileged Software Attackers are going after the **AI developer tools** your engineers already trust, because an IDE extension runs with the same permissions as the editor that hosts it. It can run code, read your filesystem and send network requests from the workstation that holds your source code, Git identities and cloud access. Cursor distributes these extensions through its own marketplace, so your developers depend on that operator's publishing controls as well as the original vendor's. Forever Security researcher Gal Weizman notes that hijacked extensions most often trace back to stolen publishing credentials protected by a single access token. For your business, an AI coding extension deserves the same scrutiny you apply to any software with administrator-level reach into your codebase. The most important step is to **check every Cursor installation** your developers use for the fake **Claude Code v2.1.313** extension. Where you find it, remove it and **rotate every credential on that machine**, including SSH keys, Git and cloud tokens, and any secrets its environment variables point to. If you are unsure how many Cursor installations your team runs or which credentials each one can reach, a [security assessment](https://captechgroup.com/security-assessment) of your developer workstations will map that exposure so you know which keys to rotate first. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-10-31T12:34:31Z", "datePublished": "2026-10-31T12:34:31Z", "description": "A trojanized Claude Code v2.1.313 extension hit up to 5,000 Cursor users on October 29, stealing system metadata and attempting SSH backdoors. Steps to respond.", "headline": "Trojanized Claude Code Extension v2.1.313 Targets Cursor Developers", "image": [ { "@type": "ImageObject", "url": "https:\/\/images.captechgroup.com\/cdn-cgi\/image\/width=1200,format=webp,quality=85\/threat-intel\/c2efbc351c.jpg", "caption": "", "description": "Trojanized Claude Code extension v2.1.313 spreading from the Cursor marketplace to developer workstations via auto-update", "width": 1200, "height": 685 } ], "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/trojanized-claude-code-extension-v21313-targets-cu-e8bbee" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/trojanized-claude-code-extension-v21313-targets-cu-e8bbee" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "", "streetAddress": "", "addressCountry": "US" } ] } ```