AI Agents

Trojanized Claude Code Extension: What the Cursor Backdoor Teaches

By Yogesh · November 5, 2026 · 11 min read

Sources checked and dated on publication. See our editorial policy.

On October 29, 2026, two maliciously modified builds of Anthropic's Claude Code VS Code extension were downloadable from the Cursor VS Code Extension Marketplace for roughly eleven hours. The injected code tried to add an attacker-controlled SSH key, enable local SSH, open a reverse tunnel and install persistence on macOS and Windows. Cursor says the flawed code could not complete the login step on most hosts, estimates at most 5,000 users were exposed, and has not explained how the attacker obtained publishing access.

The short answer

Eleven-hour exposure, two versions — Cursor's advisory says versions 2.1.312 and 2.1.313 of Anthropic.claude-code for Windows and macOS were available between about 2:27am and 1:35pm PT on October 29, 2026. Its October 30 update clarified that both versions were affected; much early coverage named only 2.1.313.
What the payload actually did — The injected JavaScript ran when the extension module loaded, collected host details and environment-variable names, appended an Ed25519 key labelled svc-telemetry to authorized_keys, and attempted a reverse SSH tunnel with roughly 60-second retries and platform-specific persistence.
The important failure — Cursor says enabling the local SSH service requires admin rights the extension lacks on most macOS and Windows hosts, so the attacker could not have logged in through the tunnel there. The key, persistence artifacts and host details were still written, so Cursor advises remediating regardless.
What remains unknown — Cursor says at most 5,000 users were exposed — a vendor estimate, not a count of compromised machines. No source reports a confirmed attacker login, data theft or attribution, and neither Cursor nor Anthropic has disclosed how the malicious upload happened.

What happened, and how big it was

Cursor says the window was about 2:27am to 1:35pm PT on October 29, 2026 — roughly eleven hours. Microsoft Threat Intelligence, which analyzed the injected JavaScript, confirms the same window and both version numbers. Wired reported that the rogue extension was live for about 11 hours on the Thursday and quoted Cursor's estimate of "at most 5,000 users". That figure is a vendor estimate of people who may have downloaded or updated to the affected builds, not a count of machines confirmed compromised; no source published a verified count of successful backdoors.

One detail is easy to get wrong. Much of the first-day coverage named only version 2.1.313. Cursor's notice carries a footer — "Update: Oct 30, 2026, 11:30 am PT: We updated the IOCs and clarified affected versions" — and its current headline and indicators of compromise cover both 2.1.312 and 2.1.313, with four VSIX hashes for the darwin-arm64 and win32-x64 builds. If you are checking logs, check both. Cursor also says it removed the malicious builds immediately, fully shut down the marketplace out of caution, audited access and "confirmed no other extensions were tampered with," rotated its keys, rebuilt the marketplace, and worked with the hosting provider to take the attacker's server offline.

What the injected code actually did

Both Cursor and Microsoft describe the same chain. A JavaScript loader prepended to extension.js executed when the module loaded — before the legitimate extension initialization, with no user interaction and no Claude conversation required. Microsoft says the loader "can use Node.js APIs to collect host information, modify files, and execute operating-system commands," and that it uses embedded components and built-in system tools rather than downloading a second executable.

The reconnaissance was narrow but revealing: hostname, username, OS, architecture, home and working directories, configured Git email, public IP, and the names of up to forty environment variables containing terms like KEY, TOKEN, SECRET, PASS, AWS or GCP. Microsoft is explicit that the callback "sends matching environment-variable names, not values," so the beacon reveals configuration categories but does not by itself demonstrate theft of the secrets. Public IP lookups went to legitimate services such as ifconfig.me and api.ipify.org; Cursor notes that accessing those services alone is not an indicator of compromise.

The payload then appended an attacker-controlled Ed25519 public key with the comment svc-telemetry to ~/.ssh/authorized_keys, attempted to enable the local SSH service, and requested a reverse tunnel (ssh -N -R '*:0:localhost:22') to an attacker server at 134.209.82.225. Persistence was written outside the extension directory: a macOS LaunchAgent named com.apple.sysmond.plist, a Windows scheduled task named SysMon with a Startup-folder fallback, and Linux cron entries present in the code. Cursor lists scripts including ~/.config/.smt and .smtk, and says the background scripts retry the tunnel roughly every 60 seconds. A delayed HTTP POST to a /beacon endpoint on the same server reported the collected host details.

The flaw that limited the damage — and why cleanup still matters

Here is the part many headlines skipped. Cursor states that "turning on the local SSH service requires admin rights, which the malicious extension does not have on most macOS and Windows hosts," and that errors in the malicious code would also cause the step to fail. "On those hosts the step fails and the attacker could not have logged in through the tunnel." Microsoft echoes this, cautioning that "a running SSH process does not necessarily mean the attacker gained access" and that its reconstructed attack chain "does not prove that every step succeeded on every host." Wired's summary framed the same finding as a lucky break: flawed code blocked the attacker from fully establishing itself on the vast majority of targets.

That is not the same as "nothing happened." Cursor says the extension still added the attacker's SSH key, installed persistence and sent host details, and its advice is to "follow the remediation steps below regardless." Microsoft adds the operational nuance that "the loader may still write keys and persistence artifacts even when tunnel access fails." Its guidance is to preserve the extension package, modified SSH authorization files, generated keys and scripts, and startup configuration before cleanup; confirm the key against the published fingerprint before removing only that entry; inspect each startup object's configured action because names like SysMon can resemble legitimate monitoring software; and note that "removing or updating the extension does not remove artifacts written outside its installation directory." A missing svc-telemetry marker alone should not replace a review of installation, process, network and persistence evidence.

Cursor's five-step response is concrete: run its check script, search endpoint/network/extension-installation telemetry against the published indicators, isolate hosts with evidence of payload execution or backdoor installation, remove the unauthorized key and persistence while assessing whether the host should be rebuilt ("uninstalling the extension may not be sufficient"), and rotate credentials and sessions accessible from affected hosts from a trusted system. Its published check is a one-liner — on macOS, grep -qs svc-telemetry ~/.ssh/authorized_keys — and it ships remediate-macos.sh and remediate-windows.ps1. Microsoft separately recommends preserving evidence first. If you suspect exposure, use the vendor's own scripts and IoCs rather than a paraphrase in a news article.

The correction: it was Cursor's marketplace, not Open VSX or Anthropic

A supply-chain story is only useful if the supply chain is identified correctly, and this one was initially misreported. Early coverage — including the discoverer Phorion's advisory, Help Net Security's body text and StepSecurity's introduction — attributed the malicious build to the Open VSX registry, and some early commentary speculated that Anthropic itself had been compromised. Those claims were corrected. OpenSourceMalware rewrote its analysis to explain that the build came from Cursor's internal mirror/proxy of Open VSX, not the public registry, and The Hacker News printed an explicit correction. Microsoft says it "confirmed that the malicious packages found on Cursor marketplace were never published nor distributed from Microsoft Visual Studio Marketplace and from npm @antropic-ai/claude-code," that "Anthropic confirmed to Microsoft that their systems were not compromised," and that "all evidence suggests that the incident is limited to Cursor marketplace." SecurityWeek reports the modified versions were not pushed to the Microsoft Marketplace, Open VSX or npm. Wired quotes Anthropic's Felix Rieseberg: "it wasn't a compromise of Anthropic's systems or employee laptops … The versions on our official channels are not affected and this only impacts Cursor users."

Some sources still carry the uncorrected version, so treat any page blaming Open VSX or an Anthropic breach as out of date. What genuinely remains unknown is the root cause: Wired notes that Cursor did not return its request for comment about how the malicious upload happened or whether it resulted from a breach at Cursor, and The Hacker News says the mechanism is still not known. Cursor rotating keys and rebuilding the marketplace is suggestive, but it is inference, not a disclosed fact. There is no published CVE — this was a malicious-package incident rather than a code flaw in Claude Code — and no attribution. Microsoft says its MITRE mappings "do not establish attribution to a particular threat actor."

Why an editor extension has this much power

The lasting lesson is about permissions, not about any single model. Microsoft's official VS Code documentation states that "the extension host has the same permissions as VS Code itself," so an extension "can read and write files on your machine, make network requests, run external processes, and modify workspace settings." VS Code has added a publisher-trust prompt since version 1.97, but the same doc notes that publishers of extensions you installed previously "are considered trusted and are automatically added to the list of trusted publishers." That is precisely the trust an auto-update inherits — a real publisher identity, not a typosquat.

Three official documentation sets give practical, sourced controls. VS Code enterprise settings allow extensions.allowed rules by publisher, extension ID, specific version and platform, with a documented caveat that locally supplied VSIX packages are not origin-verified by those rules. Cursor's own extension documentation warns that "the same publisher.extension name can point to different publishers or code on Open VSX than on the Microsoft Marketplace," advises treating extension IDs like dependencies, and documents an install cooldown that defers installs and updates until a marketplace version has been public for a set number of hours — "a buffer against short-lived malicious uploads" — plus allowed-extension lists and signature verification. The cooldown defaults to 0, meaning disabled. Microsoft's threat-intelligence post explicitly recommends applying those Cursor controls, "including restricting extensions to approved publishers and configuring an extension installation cooldown."

Anthropic's plugin security documentation covers a different surface — Claude Code plugins, not VS Code extensions — and should not be conflated with this incident, but the principle is the same: "A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges," and with auto-update on, "the files you reviewed can change on disk." It recommends reviewing hooks/hooks.json, .mcp.json and bin/ before installing, and offers claude plugin details <name> for inspecting installed copies. Microsoft's separate VS Code agent-security guidance adds Workspace Trust, keeping auto-approval scoped to the session and reviewing MCP servers before trusting them. None of these controls is sufficient alone — Cursor's own documentation says as much — but an allowlist plus a nonzero install cooldown would have directly blunted an eleven-hour malicious upload.

Verdict If you installed or updated Anthropic.claude-code 2.1.312 or 2.1.313 from Cursor's marketplace on macOS or Windows on October 29: check for the svc-telemetry key, preserve evidence, use Cursor's remediation scripts, and rotate credentials from a clean machine. Do not assume the failed SSH step means the host is clean.

For teams: This was a marketplace supply-chain failure, not an AI-model failure. Enable an extension install cooldown (the default is off), allowlist approved publishers and versions, require signature verification, and review trusted-publisher lists periodically.

For everyone else: Resist both the alarming and the reassuring headline. No confirmed attacker logins or data theft have been published, and the root cause is still unknown. The useful output of this incident is an audited extension inventory, not a verdict about Claude Code itself.

Bottom line: A real, verified publisher channel served a trojanized Claude Code update for about eleven hours, and the payload ran on module load with the full privileges of the editor. The attacker's SSH step mostly failed, but the key, persistence and host beacon remain reasons to remediate. The unresolved question — how the upload got publishing access — is the one the industry still needs answered. Until it is, treat editor extensions like production dependencies: pinned, allowlisted, and updated on a delay.

Frequently asked questions

Eleven-hour exposure, two versions

Cursor's advisory says versions 2.1.312 and 2.1.313 of Anthropic.claude-code for Windows and macOS were available between about 2:27am and 1:35pm PT on October 29, 2026. Its October 30 update clarified that both versions were affected; much early coverage named only 2.1.313.

What the payload actually did

The injected JavaScript ran when the extension module loaded, collected host details and environment-variable names, appended an Ed25519 key labelled svc-telemetry to authorized_keys, and attempted a reverse SSH tunnel with roughly 60-second retries and platform-specific persistence.

The important failure

Cursor says enabling the local SSH service requires admin rights the extension lacks on most macOS and Windows hosts, so the attacker could not have logged in through the tunnel there. The key, persistence artifacts and host details were still written, so Cursor advises remediating regardless.

What remains unknown

Cursor says at most 5,000 users were exposed — a vendor estimate, not a count of compromised machines. No source reports a confirmed attacker login, data theft or attribution, and neither Cursor nor Anthropic has disclosed how the malicious upload happened.

Sources

Prices and benchmark figures are standard published rates as of November 5, 2026 and can change without notice. Some outbound links may be affiliate links — see our disclosure. Found an error? Tell us and we'll correct it in public.