What happened in the Claude Code extension backdoor?
On 29 October 2026, developers who updated Anthropic's Claude Code extension through Cursor's marketplace received a build that Anthropic did not develop. The package carried a small loader inside its main JavaScript bundle. When the editor loaded the extension, the loader ran. It planted an SSH key, tried to open a tunnel, and sent host details to an external server.
Cursor published a security notice the same day. It named versions 2.1.312 and 2.1.313 for macOS and Windows. The malicious builds were available from about 2:27 a.m. to 1:35 p.m. Pacific Time, the company said. That window is roughly 11 hours, or 09:27 to 20:35 UTC.
StepSecurity measured the tampered extension.js file at 3,692,922 bytes, about 7 KB larger than the preceding release. The extra code was a self-contained loader prepended to an otherwise normal bundle. The rest of the file still contained the usual Claude Code strings and the standard activate and deactivate exports.
Cursor estimates that up to 5,000 users received the build. Sophos X-Ops and StepSecurity both attribute that figure to the company. Cursor removed the affected version and blocked further distribution. It then shut its marketplace down, rotated keys, rebuilt the service and brought it back online.
The package name was anthropic.claude-code. The publisher namespace belonged to Anthropic. Nothing about the listing looked like a typosquat, which is why the update could spread without obvious alarm. StepSecurity says the Anthropic namespace on Open VSX has been published by an Anthropic employee since 2025.
The public reporting concerns the local extension package. It does not describe an intrusion into Anthropic's model serving or API. The Claude model was not the delivery mechanism here. The delivery mechanism was a hijacked update channel.
Why did one Open VSX upload reach Cursor users?
Cursor's marketplace draws on Open VSX, the vendor-neutral registry that supplies extensions to several VS Code-compatible editors. StepSecurity lists VSCodium, Cursor, Windsurf and Gitpod among the registry's consumers. One publish upstream can therefore reach many downstream editors.
"One upstream publish on Open VSX propagated automatically to every downstream consumer of the registry," StepSecurity wrote in its analysis. That sentence describes the structural weakness. A mirror inherits the trust of its source, often within minutes and without a second security review.
The scale of the package made the disguise convincing. The Claude Code extension has 63,117,471 lifetime downloads on Open VSX as of 30 October, according to the registry's own listing. The affected group was a small fraction of that total: Cursor estimates up to 5,000 users. Even so, the registry entry is what made the tampered build look official.
Microsoft's Visual Studio Marketplace was not the distribution path named by Cursor. StepSecurity says the Microsoft download endpoint returns 404 for 2.1.313 while serving the neighbouring versions. That is narrow good news. It does not prove that every VS Code user was safe, because other forks also pull from Open VSX.
Mirrors exist because editors want a catalogue that works without Microsoft's marketplace. The arrangement saves each editor from negotiating with thousands of publishers. It also leaves the mirror operator with little independent evidence about a new upload beyond the upstream listing. A version number is only as trustworthy as the account that published it.
The registry listing now serves version 2.1.314, which Open VSX records as published on 30 October at 01:07 UTC. StepSecurity downloaded that build and reports that it contains none of the malicious indicators.
What did the malicious extension do to a developer machine?
The loader ran before the extension's normal activate function. No chat message, command or click was needed. Loading the module was enough. That detail matters because developers expect an extension to act only when they use it. Here, opening the editor was sufficient.
The first stage wrote an attacker-controlled Ed25519 public key into ~/.ssh/authorized_keys. The key carried the comment svc-telemetry. The script set permissions to 0700 on the .ssh directory and 0600 on the file. Anyone holding the matching private key could then log in as that user, provided SSH was running.
The second stage opened a reverse SSH tunnel to 134.209.82.225 as the user tunnel. It used a second embedded key, labelled svc-telemetry-tun, and remote port forwarding of *:0:localhost:22. The connection ran detached, outside the editor, and retried roughly every 60 seconds. Closing Cursor did not stop it.
Persistence varied by platform. On macOS, the payload wrote a LaunchAgent named com.apple.sysmond.plist with RunAtLoad and KeepAlive enabled. On Windows, it tried to create a scheduled task called SysMon that ran as SYSTEM, with a Startup-folder script as a fallback. Linux code paths also existed, including a cron entry, although the Cursor builds identified by the company were for macOS and Windows.
The loader also collected host information. Phorion's analysis lists the hostname, username, operating system, architecture, home directory, working directory, Git email and public IP. It also read the names of up to 40 environment variables matching patterns such as KEY, TOKEN, SECRET, PASS, AWS and GCP. According to Phorion, it sent the names, not the values.
The data went by plain HTTP POST to port 8099 on the same address. A second copy was aimed at 127.0.0.1:8099, for reasons the analysts could not establish. The beacon was designed as a one-off check-in, while the tunnel handled interactive access.
The two keys served different purposes, and investigators need to keep them apart. The public key in authorized_keys let the operator log in to the victim. The embedded private key let the victim's machine authenticate to the operator's tunnel server. Removing only one leaves half the chain intact.
The attack partly failed for mundane reasons. Enabling SSH requires administrator rights, which the extension did not have on most hosts. Cursor says the step failed outside unusual cases where the editor was started as administrator. Phorion also found a macOS logic bug. A permission error from systemsetup was mistaken for evidence that Remote Login was already on, so the script skipped the enablement step.
Phorion found further implementation errors. The Windows service setup was passed through a helper that hard-coded /bin/sh, which would not work on a standard Windows install. On Linux, a faulty check in the cron logic could delete existing user cron jobs when the script ran more than once. These bugs limited the attack but complicate clean-up.
That failure reduced the impact but did not remove it. The attacker's key and the persistence files still landed. Cursor says uninstalling the extension may not be sufficient, because the payload drops standalone scripts that keep running. The company also says it worked with the hosting provider to take the attacker server offline.
Who is affected, and how do you check?
The exposure is limited to macOS and Windows users of Cursor. It covers people who installed or updated anthropic.claude-code 2.1.312 or 2.1.313 from its marketplace during the window. Cursor says it has no evidence that other versions or the official distribution were affected. That is an assurance about the packages Cursor examined, not a clean bill of health for every marketplace.
The simplest check is the SSH key. On macOS, run: grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted". On Windows, search both $HOME\.ssh\authorized_keys and C:\ProgramData\ssh\administrators_authorized_keys for the same string.
If the key is present, treat the machine as compromised. Cursor's guidance is to isolate the host and remove the key. Teams should also unload the persistence, stop the tunnel processes and rotate credentials from a trusted system. The company publishes remediation scripts for macOS and Windows. It also suggests assessing whether the machine should be rebuilt.
Security teams should look beyond the key. Useful signals include an IDE helper process writing to authorized_keys. Also look for a LaunchAgent or scheduled task named sysmond or SysMon, and outbound SSH to 134.209.82.225. Phorion notes that a successful attacker login would appear in SSH logs as a connection from localhost.
Investigators should also check Linux artefacts. Cursor's builds were aimed at macOS and Windows. The payload still contains Linux paths, including ~/.config/.smt and a cron entry that runs it at reboot. Phorion also describes a temporary key file named .stk_ followed by ten hexadecimal characters.
The environment-variable collection is a warning about scope. Reading names rather than values suggests the operator wanted an inventory of which machines held cloud keys. It does not prove that no secret was taken, especially if the tunnel ever worked. Rotating credentials reachable from an affected laptop is the safer response.
What is still unknown about the incident?
The root cause is unresolved in public. A malicious build appeared under a namespace controlled by Anthropic, but no one has explained how it got there. StepSecurity says the mechanism, whether compromised publisher credentials or something else, has not been publicly established. Cursor states that the malicious versions were not developed by Anthropic. Neither company has named a suspect.
There is also a version discrepancy. Cursor's notice lists both 2.1.312 and 2.1.313 as malicious and publishes hashes for both. StepSecurity downloaded 2.1.312 from Open VSX and found it clean, and it describes 2.1.313 as the trojanized build. The two accounts have not been reconciled in public.
No public tally exists of hosts where an attacker actually logged in. Cursor says the SSH step failed on most machines because it needed administrator rights. The key would still work on a host that already had Remote Login enabled. It would also work on a host where a user later turned it on. Researchers have not published evidence of follow-on intrusions.
The motive is also inference. The payload's interest in API keys, cloud credentials and Git identity points to credential theft. That fits the economics of developer tooling, where one laptop can hold production access. It does not establish who ran the operation or what they wanted. The single IP address offers little attribution on its own.
This is not the first abuse of the registry. In March 2026, Socket reported at least 72 more malicious Open VSX extensions linked to GlassWorm. The count starts on 31 January 2026. Those were largely loader packages with transitive dependencies. The Claude Code case is different because it used a trusted publisher name, which makes it harder to filter.
Cursor says it audited access and found no sign that other extensions were tampered with. It also rotated its keys and rebuilt the marketplace before restoring it. Those steps address the distribution channel. They do not explain the original publish, and they do not tell an affected developer whether anyone used the key.
What does the Claude Code backdoor mean for AI coding tools?
AI coding tools concentrate valuable secrets. A typical setup holds repository tokens, cloud credentials, model API keys and SSH access on the same laptop that runs the assistant. Extensions run with the permissions of the editor and the signed-in user. There is little separation between an extension host and the files in a home directory.
That changes the threat model. The most valuable target is not always the model or its weights. It is the developer machine that can reach production systems. An attacker who can publish one plausible update does not need a jailbreak, a prompt injection or a new exploit. They need a trusted name and a few hours.
The incident also shows the limits of familiar trust signals. The publisher name was correct. The install count was enormous. The extension was the official integration, not a lookalike. Users who checked those signals would have seen nothing unusual. Registry mirrors add another layer that users cannot easily inspect.
Claude Code is itself an agentic tool with shell access. That makes the extension a natural entry point, because the assistant already has permission to read repositories and run commands. A backdoor does not need to impersonate the assistant. It only needs to arrive alongside it.
Practical controls are unglamorous. Pin extension versions and review updates in regulated teams. Allowlist extensions rather than permitting every marketplace item. Avoid running an editor as administrator. Prefer hardware-backed SSH keys and short-lived cloud credentials. Monitor writes to authorized_keys and new LaunchAgents or scheduled tasks on developer fleets.
The next signals to watch are disclosure and registry design. A full root-cause report would show whether a credential was stolen, a build pipeline was abused or a publishing console was compromised. Changes to Open VSX publishing controls, signing and provenance would matter more than another round of takedowns. So would details of Cursor's marketplace rebuild and key rotation.
For now, the incident is a reminder that AI tooling sits on ordinary software supply chains. The model may be new. The attack path, a trusted update that runs on load, is decades old. The fix has to cover both the assistant and the pipeline that delivers it.