The Extension Was Real, the Publisher Was Real, and the Key Survives the Uninstall

The version number is the only thing that was fake.

By Thursday afternoon, the shorthand for this story had hardened into something like "Anthropic's Claude Code extension was backdoored." That is wrong in the way that matters. Nobody touched Anthropic's build pipeline, nobody took an employee laptop, and the bundled Claude binary inside the extension is unmodified. What Cursor served to as many as 5,000 developers was the real extension with 66 lines bolted onto the front of its JavaScript bundle: 3,692,922 bytes of extension.js, roughly 7 KB heavier than the clean release it replaced.

Those 66 lines ran when Node loaded the module. Not when someone opened a Claude conversation, not through a package-manager install hook, not on a click. An editor loading an extension is enough. Between 09:27 and 20:35 UTC on 29 October, a window of eleven hours and eight minutes, every Cursor install that pulled or auto-updated anthropic.claude-code during that window got the loader and everything behind it.

What the loader actually did

It did four things, in order, beginning the moment the module loads. First, it read the machine: hostname, username, operating system, architecture, home directory, working directory, the global Git email, the public IP from ifconfig.me and api.ipify.org. It also walked the environment and kept the names, not the values, of up to forty variables matching KEY, TOKEN, SECRET, PASS, AWS or GCP. Microsoft's Threat Intelligence team, which pulled the payload apart and published its analysis on 30 October, is precise about the distinction. Names only. The beacon tells an operator which credentials exist on a box so they can decide which box to come back to, and Phorion's read, given to Ars Technica, is that the inventory was likely built to prioritise follow-up targets. Nothing in the beacon proves a secret was taken.

Second, it wrote an Ed25519 public key, commented svc-telemetry, into ~/.ssh/authorized_keys and tried to switch on the local SSH service. Third, it decoded a separate private key, wrote it to a hidden .stk_ file in the temp directory, and started an outbound connection to [email protected] asking for a remote port forwarded back to localhost:22. Fourth came persistence, under names chosen to survive a glance at a process list: a LaunchAgent called com.apple.sysmond.plist on macOS, a scheduled task called SysMon requesting SYSTEM on Windows with a Startup-folder fallback, and, in the Linux code path, an @reboot cron entry. A background loop retries the tunnel every sixty seconds. The extension itself kept working normally throughout, which is the point.

The coding errors that saved the quarter

The tunnel mostly did not work. Cursor says so in its own notice, and the company is unusually candid about why: the step that enables the SSH service needs administrator rights the extension did not have, and errors in the malicious code meant the attempt failed even where they might have been available. On a standard macOS or Windows workstation, the attacker got a key, persistence and a beacon, but no shell.

Calum Hall, chief executive of Phorion, the detection firm that found this on a customer's Mac first, put it to WIRED without much diplomacy: "Everyone was so lucky here, this was potentially a really dangerous foothold for an attacker."

Lucky is the right word. Nothing in the design prevented it. The failure was a permissions assumption and a couple of bugs, not a control.

Uninstalling fixes nothing

Installing 2.1.314 does not fix any of it.

The artifacts the loader writes live outside the extension directory. Cursor's notice says it plainly: uninstalling the extension may not be enough, because the payload drops standalone persistence scripts that keep running. Microsoft goes further, because Cursor's reported takedown of the attacker's server does not remove anything already sitting on a disk. The key stays in authorized_keys. The LaunchAgent stays loaded. The retry loop keeps dialling.

So the remediation is a hunt, not an update. Find the svc-telemetry key by comment or by fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk. Check both authorized_keys locations on Windows. Look for .smt and .smtk under ~/.config, .stk_* in temp, a SysMon task, a com.apple.sysmond label. Kill the ssh -N -R '*:0:localhost:22' process and the shell loop that restarts it. Then rotate every credential that machine could reach, from a different machine. Cursor published remediation scripts for macOS and Windows; there is no official one for Linux, so that path is manual.

For a fleet, that is a person, per endpoint, at a shell. Multiply by the number of developers running a VS Code fork.

The question neither vendor has answered

How did a build Anthropic did not produce get published under Anthropic's own identity?

Anthropic's position, stated by Felix Rieseberg on X and repeated by security engineer David Dworken: this was not a compromise of Anthropic systems or employee laptops, the company did not build or publish the tampered copy, and its official channels were unaffected. Dworken added that 2.1.313 was never published to Open VSX, the Microsoft Marketplace or any Anthropic host, and that the next release was numbered 2.1.314 specifically to disambiguate. As of this morning, Anthropic's newsroom carries no post about the incident; the company's public account remains two staff statements on X.

Socket's registry work supports part of that and makes the rest stranger. The firm audited 3,392 entries in Open VSX's append-only change feed from 27 October and found publication and removal events for all eight platform builds of 2.1.312 and 2.1.314, and none at all for 2.1.313. In the same window it counted 42 versions across 21 other extensions published and then withdrawn, every one of which retained both events, including a version pulled about ninety seconds after it appeared. npm's metadata has no 2.1.313 either, and npm keeps publication timestamps for versions that were later unpublished. Microsoft confirmed independently that neither its marketplace nor the npm package was involved.

Which leaves Cursor's marketplace as the only place 2.1.313 existed. Kevin Beaumont and Phorion's Luke Roberts both say it was posted to Anthropic's official account on Cursor, superseding 2.1.312, which is not the same thing as a lookalike listing under a similar name. Roberts told Ars it was "a supply-chain compromise where the attacker gained access to the official distribution channel."

Cursor has not said how. Its notice named only 2.1.313 on Thursday and added 2.1.312 the following morning; both builds served from Cursor were tampered. Neither company answered Ars Technica's questions on the point, and Cursor did not answer WIRED's. Cursor shut the marketplace down entirely, rotated its keys, audited access, found no other tampered extensions and rebuilt. Shutting and rebuilding reads like a distributor that cannot yet rule out its own publishing path as the vector. It is not a root cause.

The control that spread it is the control everyone depends on

Extensions auto-update by default in Cursor. That default is why as many as five thousand machines got this within eleven hours of publication, and it is also the only reason most fleets are patched at all.

The mitigation Microsoft points to is not technical. It is Cursor's own hardening guidance: restrict extension installs to approved publishers, and set an install cooldown so that a newly published version has to sit for a number of hours before it reaches a workstation. A cooldown of a single day would have emptied this entire window: the malicious build was pulled eleven hours after it appeared, so no machine with a 24-hour floor would have installed it at all.

None of that is exotic. It is the same reasoning that put change freezes and staged rollouts into every other part of the estate years ago. Developer tooling has simply been exempt, on the assumption that the people using it are technical enough to be trusted with the keys.

What a buyer should be asking

The uncomfortable part is not that a marketplace got compromised. Marketplaces get compromised. The uncomfortable part is that most organisations cannot answer the only question that decides whether this touched them: which extensions, at which versions, are installed on which developer machines, right now.

As Mondoo's researchers point out, most endpoint software inventories do not list editor extensions at all. There are several of those directories per machine, one per VS Code fork, and Cursor, Windsurf, VSCodium and the rest each resolve their own. Asset databases built around installed applications see an editor. They do not see what the editor is running.

Firmware had the same shape of problem last week, and the answer there was also a purchasing one: which BIOS release carries the fix, and when. The version of that question for developer tooling is who approves a publisher identity, and how many hours a new version has to exist before it lands on a laptop. Neither answer comes from a scanner. Both are decisions made before an incident, by whoever owns the toolchain.

If your organisation is still treating developer workstations as personal property with a corporate laptop attached, let's talk about what it takes to bring them under the same change control as everything else.