Claude Code 2.1.312 and 2.1.313: What Actually Got Backdoored

"Claude Code 2.1.312 and 2.1.313 were trojaned" is going around, often with the advice to uninstall Claude Code completely. Part of that is true. Part of it is not, and the difference decides whether you need to do anything at all.

Short version: the backdoored builds were tampered copies of the Claude Code VS Code extension (anthropic.claude-code) served through Cursor's own extension marketplace, for macOS and Windows, for about eleven hours on October 29, 2026. The Claude Code CLI on npm was not affected, and neither were the copies on the official VS Code Marketplace or Open VSX.

What happened

Cursor published a security notice on October 29. It says a maliciously modified version of Anthropic's Claude Code extension was available in the Cursor VS Code Extension Marketplace between about 2:27 AM and 1:35 PM Pacific time that day. In WIB, that is roughly 16:27 on October 29 to 03:35 on October 30. Cursor's first statement put the exposure at up to 5,000 users. The notice first named only 2.1.313. An update on October 30 added 2.1.312, for both Windows and macOS.

Cursor says these builds were not developed by Anthropic. Two Anthropic engineers said the same thing publicly on Hacker News: it was not a compromise of Anthropic's systems or employee laptops, a malicious actor used access to Cursor's marketplace to publish a tampered copy, and the versions on Anthropic's official channels were not affected. Microsoft says the malicious packages were never published to or distributed from the Visual Studio Marketplace or npm, and that Anthropic confirmed to them its systems were not compromised.

What nobody has explained publicly yet is how the attacker got that access to Cursor's marketplace. Cursor's notice describes the cleanup (pulling the version, shutting the marketplace down, rotating keys, rebuilding it, auditing other extensions) but not the root cause. I would treat that as an open question.

Checking the claim against the registries

I did not want to repeat anyone's summary, so I looked at the public metadata myself. Read-only, nothing downloaded or run.

Anthropic says 2.1.313 was never published on any of its official hosts, and that it made the next real update 2.1.314 to avoid confusion. So there is no legitimate 2.1.313 anywhere. If you have it, it came from Cursor's marketplace.

2.1.312 is the confusing one, because it is a real Anthropic release. The npm CLI 2.1.312 is legitimate. StepSecurity downloaded the 2.1.312 extension from Open VSX and verified it clean. Only the 2.1.312 builds that Cursor's marketplace served during the window were tampered. The version number alone does not tell you which one you have.

One more thing worth knowing: the early reports blamed Open VSX, and one initially named npm and the Microsoft marketplace too. Those claims have since been corrected. A lot of the reposted summaries still carry the old version.

What the payload does

Several teams analysed the sample. StepSecurity recovered the malicious extension.js and read it statically. It is the official 2.1.312 bundle with a roughly 7 KB loader prepended to the front. It is not obfuscated. Even the "2.1.313" build still identifies itself as 2.1.312 inside the bundle; only the repackaged manifest was bumped.

The loader runs as soon as the extension module loads. You do not need to open a Claude session. According to Cursor, Microsoft, and StepSecurity, it:

Some context that keeps this from sounding worse than it is:

But I would not stop there. Microsoft points out the loader can still write the SSH key and the persistence files even when the tunnel fails, and those stay on disk after you uninstall or update the extension. Taking the server offline does not remove anything from your machine. And if the SSH step did succeed somewhere, for example on a Mac where SSH was already on, the attacker had interactive access for as long as the tunnel was up. The env var names are basically a map of which credentials were on that machine.

Am I affected?

You are only in scope if all of these are true:

If you only use Claude Code from the terminal via npm, run claude --version if you like, but this incident does not touch you. The same goes for the extension in VS Code from Microsoft's marketplace.

If you do use Cursor, here is what I ran.

1. Look for the attacker key. Cursor's own check on macOS:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found"

On Windows, in PowerShell:

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found" }

The loader only checks for the comment string before appending, and the original Phorion writeup suggests also matching on the key fingerprint rather than just the comment. On macOS or Linux:

ssh-keygen -lf ~/.ssh/authorized_keys | grep '0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk'

Any output there means the attacker key is present.

2. Look for the persistence files, which can exist even if the key check is clean:

ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null
ls -la "$TMPDIR"/.stk_* 2>/dev/null

On Windows, check for %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_*, a scheduled task called SysMon (schtasks /query /tn SysMon), and sysmon.cmd in your Startup folder.

3. Look for running tunnel processes:

ps aux | grep -E "ssh .*-R \*:0:localhost:22|autossh" | grep -v grep

4. Check whether SSH was actually reachable. On a Mac, see if Remote Login is on with sudo systemsetup -getremotelogin. If it was on during the window, check your SSH logs too. Phorion notes that a login through the tunnel would look like it came from localhost and used the svc-telemetry key.

5. Check the installed extension itself. Cursor keeps extensions under ~/.cursor/extensions. Listing that folder shows which anthropic.claude-code-* version is installed. Cursor's notice says the malicious extension.js contains the string svc-telemetry, so this flags a tampered copy that is still on disk:

ls ~/.cursor/extensions | grep anthropic.claude-code
grep -rl svc-telemetry ~/.cursor/extensions/anthropic.claude-code-* 2>/dev/null

The full list of hashes and network indicators, including the attacker's address for searching firewall or EDR logs, is in Cursor's notice and Microsoft's writeup. I am not going to copy it here, so you get it from the source.

If you find something

Cursor's steps, in short:

Microsoft also suggests keeping a copy of the extension package, the changed authorized_keys, and the dropped files before cleaning up, in case you need to investigate later. On a work laptop, tell your security team before you delete anything.

What I am changing

This was not a bug in Claude Code. It was a distribution problem: an editor extension that most of us auto-update without a second thought. A few things I am doing now:

My take

The headline is accurate in the narrow sense that Claude Code 2.1.312 and 2.1.313 builds carrying a backdoor did reach real machines. It is wrong if it makes you think the claude CLI or Anthropic's own release pipeline was hijacked. Nothing I could check supports that, and the registries point the other way.

If you are on Cursor on a Mac or Windows machine and the extension auto-updated between Thursday afternoon and early Friday morning WIB, spend ten minutes on the checks above today. If you are not, there is nothing to uninstall. Just keep an eye on how Cursor explains the root cause, because that part is still missing.

Sources