A Backdoored Claude Code Extension Sat on Cursor's Marketplace for 11 Hours: What Development Teams Should Check Now

For about eleven hours on Thursday 29 October 2026 developers who installed or auto-updated the Claude Code extension through the Cursor editor's marketplace received something extra. A loader inserted at the top of the extension's code quietly profiled the machine, dropped an attacker's SSH key into the user's authorised keys, tried to open a reverse tunnel to a remote server and installed itself to survive a reboot. Cursor, which runs the marketplace, pulled the builds at 20:35 UTC, shut the whole marketplace down, rotated its keys and rebuilt it. Up to 5,000 of its users may have been exposed.

The attack targeted one of the most widely used AI coding tools of the year, which is why it made headlines. The reason it belongs in this column is more general. An IDE extension runs with the full rights of the developer who installed it, on the machine that holds the source code, cloud credentials and deployment tokens of their employer. A trojanised extension is a trojanised employee.

What Happened

According to Cursor's security notice, versions 2.1.312 and 2.1.313 of the Anthropic.claude-code extension became available on its marketplace at about 02:27 Pacific time, 09:27 UTC, on 29 October. The builds were for Windows and macOS only and, Cursor says, "were not developed by Anthropic." At 13:35 Pacific, 20:35 UTC, Cursor removed them and blocked further distribution. The company then took its entire extension marketplace offline as a precaution, audited access, confirmed that no other extensions had been tampered with, rotated keys and rebuilt the marketplace before bringing it back. On 30 October it worked with the hosting provider to take the attacker's server, at 134.209.82.225, offline. Cursor updated the notice on 30 October with revised indicators of compromise and a clarification of the affected versions.

Anthropic's position, as relayed by StepSecurity, is that its own systems, employee laptops and official distribution channels were not compromised, that it did not build or publish the tampered version, and that 2.1.313 was never published to Open VSX, the Microsoft Visual Studio Marketplace or its other official hosts. It skipped straight to 2.1.314 to avoid confusion. StepSecurity's write-up, which originally described Open VSX as the origin, was corrected after the researchers downloaded and verified that the 2.1.312 build served by Open VSX is a different, clean artefact. Early reports that npm and Microsoft's marketplace were affected were likewise disproven, BleepingComputer reports; the only distribution channel was Cursor's marketplace.

Inside the payload

Researchers at Phorion, OpenSourceMalware and StepSecurity found a JavaScript loader of roughly 7KB prepended to the extension's extension.js file. The rest of the bundle matched the clean 2.1.312 release. The loader ran under plain Node.js as soon as the extension loaded, with no need for the developer to use Claude Code at all, and worked through six stages. It collected the hostname, username, platform and architecture, home and working directories, the Git email address, the public IP address and the names, though not the values, of environment variables that looked like credentials. It wrote an Ed25519 public key labelled svc-telemetry into the user's ~/.ssh/authorized_keys. It tried to enable the SSH service, using systemsetup on macOS where passwordless sudo was available and the OpenSSH Server feature on Windows. It opened a reverse SSH tunnel to the attacker's server and retried it every 60 seconds. It installed persistence as a LaunchAgent named to resemble an Apple system process on macOS, and as a SYSTEM scheduled task called SysMon with a Startup folder script as fallback on Windows. Finally it sent the reconnaissance data to the server.

Two details soften the picture without changing the lesson. First, the code was sloppy. BleepingComputer notes that on macOS the SSH setup ran without administrator rights and on Windows the script tried to use /bin/sh, which does not exist, so Cursor believes the SSH stages "would usually fail" without elevated privileges. Second, the implant did not read credential values, touch Claude or editor data, or download a second stage. The analysts' reading is that the attacker intended to come back manually over SSH and work interactively on the machines where the tunnel succeeded. Even where it failed, the beacon still told them who and where the developer was, which Git identity they used and which credential variables were worth looking for.

The open question

Nobody has yet explained how the attacker was able to publish under Anthropic's name on Cursor's marketplace. Cursor's notice says only that it "identified" the incident, and both BleepingComputer and StepSecurity list the publishing path, and whether an account or token was compromised, as unanswered. Until that is known, the fair summary is that the extension's publisher says it was not breached, the marketplace operator says the rest of its catalogue was clean, and the mechanism that let one in is unexplained.

Who Is Affected

Directly affected are Cursor users on Windows or macOS whose editor installed or auto-updated the Claude Code extension from Cursor's marketplace between 09:27 and 20:35 UTC on 29 October, a group Cursor caps at 5,000. Developers who use the extension through Visual Studio Code, Open VSX or Anthropic's own channels were not served the malicious builds. Linux users were not targeted by these builds, although the loader contained Linux persistence logic.

Indirectly affected is every organisation that employs those developers. A developer laptop typically holds source code, Git credentials, cloud and Kubernetes tokens, package registry keys, VPN configurations and access to CI/CD systems. An attacker with an interactive SSH session on it can reach a great deal without ever touching the corporate network's perimeter. Cursor's remediation guidance therefore goes beyond the machine: rotate the credentials and sessions accessible from the affected host, from a trusted system, and assess whether to rebuild it rather than clean it, because the payload drops standalone persistence scripts that survive uninstalling the extension.

The week's wider context makes the point. The same seven days saw hackers compromise the update systems of two poker table software makers to install a remote access tool, an attempted remote code execution attack on Alpine Linux's GitLab server, and continued fallout from the earlier LiteLLM and ConnectWise supply chain compromises. Developer tooling and the pipelines around it are now a routine target rather than an exotic one.

Why It Matters

Extension marketplaces are app stores that most organisations do not govern. Developers install what they need, updates arrive automatically, and the publisher's name is the only trust signal most people check. This incident shows that the name can be wrong even when the publisher has done nothing wrong, and that an eleven-hour window is long enough to reach thousands of machines. The response from Cursor, pulling the builds, taking the whole marketplace down, rotating keys and publishing hashes and remediation scripts within a day, was fast and transparent, but it was still reactive: nothing stopped the build going live.

The attack also illustrates how much reconnaissance is worth on its own. Even with the SSH stages failing, the attacker now holds a list of developer identities, Git emails, hostnames and the names of credential variables for up to 5,000 machines. That is a targeting list for the next phishing or token-theft campaign, and it does not expire when the server goes offline.

Finally, there is the question of trust in AI coding tools specifically. The tools themselves were not at fault here, but their popularity makes them attractive carriers, and the speed at which they update makes the window between a malicious publish and detection the whole game. Organisations adopting them should treat the extension, its update channel and the marketplace serving it as part of their software supply chain and govern them accordingly.

What To Do Now

Check every Cursor installation now. Search ~/.ssh/authorized_keys for the svc-telemetry key, look for the LaunchAgent, scheduled task and Startup script paths in Cursor's indicator list, and search installed extension folders for the C2 address 134.209.82.225. Treat any match as a confirmed incident: isolate the host, run Cursor's platform-specific remediation script, rotate every secret and session the machine could reach using a different trusted device, and rebuild if there is any doubt.

Block and hunt for the indicators across the estate. Add the C2 address, file hashes and persistence names to endpoint detection, DNS and proxy logs, and look back over the window of 29 to 30 October for outbound SSH from developer machines to unfamiliar hosts. A reverse tunnel retrying every minute is a loud signal if anyone is listening.

Govern extensions like any other software. Maintain an allow-list of approved extensions and marketplaces for each editor, pin versions where the tooling allows it, delay auto-updates by a day or two so that community detection has time to work, and give developers a quick way to report something that looks wrong. The same applies to CLI tools installed from package registries.

Reduce what a developer laptop can reach. Keep long-lived cloud and registry credentials out of local environment files in favour of short-lived tokens issued through a vault or identity provider, require phishing-resistant multi-factor authentication for every console a laptop can open, and separate day-to-day development from production access with dedicated privileged workstations or jump environments.

Watch developer endpoints for behaviour, not just signatures. New entries in authorized_keys, SSH services being enabled, new LaunchAgents and scheduled tasks, and outbound tunnels from an editor process are all detectable with endpoint telemetry. Make sure your monitoring covers developer machines as closely as it covers servers, because for most organisations they are now the shortest path to production.

How Cybergen Can Help

Cybergen's DevSecOps advisory and supply chain risk management services help you set and enforce rules for the extensions, packages and marketplaces your developers rely on. Our 24/7/365 managed detection and response watches developer endpoints for exactly the persistence and tunnelling behaviour seen here, and our incident response service is available if the search for svc-telemetry turns something up.

Frequently Asked Questions