The Claude Code Extension Backdoor in Cursor's Marketplace: What Happened and What to Do

A tampered build of the Claude Code extension planted an SSH backdoor the moment it loaded. No prompt, no tool call, no approval dialog. Here is what happened, how to check your machines, and what it says about the agent supply chain.

On October 29, 2026, Cursor's marketplace distributed malicious Claude Code extension builds 2.1.312 and 2.1.313 (anthropic.claude-code) for macOS and Windows. Anthropic did not build them. The payload ran as soon as the extension loaded, added an SSH key labeled svc-telemetry to authorized_keys, and installed persistence. Uninstalling the extension or updating to 2.1.314 does not remove that backdoor. Open VSX and Microsoft's Visual Studio Marketplace were not affected. Cursor has said up to 5,000 users may have been exposed.

What happened in the Cursor Claude Code extension incident?

Cursor's marketplace served tampered anthropic.claude-code builds 2.1.312 and 2.1.313 from about 2:27 a.m. to 1:35 p.m. PT on October 29, 2026. They carried the real extension ID, so they looked like any other update. If you had auto-update on, you could have received one without clicking anything.

When (PT)	What
Oct 29, ~2:27 a.m.	Tampered Claude Code builds appear in Cursor's marketplace
Oct 29, ~1:35 p.m.	Cursor pulls the version and takes the whole marketplace offline
Oct 29 to 30	Cursor audits access, rotates keys and rebuilds the marketplace; the attacker's server is taken down with the hosting provider's help
Oct 29 to 30	Anthropic publishes a clean 2.1.314
Oct 30, 11:30 a.m.	Cursor updates its notice to list both 2.1.312 and 2.1.313

Cursor says the malicious version "was not developed by Anthropic." It found no other tampered extensions and no evidence that other versions or the official distribution were affected.

How did the malicious Claude Code extension work?

The malicious Claude Code extension in Cursor contained a 66-line JavaScript loader at the top of extension.js, the extension's main bundle. The real Claude Code code sat below it, untouched, so the extension worked normally. The loader ran when the editor loaded the extension. Nobody had to open Claude, type a prompt or approve anything.

It did three things in order.

1. It collected the hostname, username, OS, CPU architecture, home and working directories, global Git email and public IP, plus the names of environment variables that looked like credentials. All of it went over plain HTTP to 134.209.82[.]225:8099/beacon.
2. It added an ed25519 key with the comment svc-telemetry to ~/.ssh/authorized_keys, tried to turn on the machine's SSH server, and opened a reverse SSH tunnel to the attacker's host.
3. It set up persistence. On macOS that was a LaunchAgent labeled com.apple.sysmond. On Windows it was a SysMon scheduled task, with a Startup-folder script as a fallback. Small scripts retry the tunnel about every 60 seconds, and they don't need Cursor to be running.

What did the malware take?

The malicious Claude Code extension's beacon sent credential-like environment variable names, not their values. According to The Hacker News, it carried the names of up to 40 environment variables containing terms like KEY, TOKEN and SECRET, along with the Git email and public IP.

That sounds harmless until you picture a real developer's shell. Names like AWS_ACCESS_KEY_ID, GITHUB_TOKEN or STRIPE_SECRET_KEY tell an attacker which cloud accounts, CI systems and payment APIs the laptop can reach. Add an SSH key that survives reboots and the attacker has a map and a way back in. One researcher put it plainly to The Hacker News: SSH access would let an operator inspect the account directly.

Developer laptops are often one hop from production. The same machine has cloud CLI sessions, deploy keys, CI tokens and a checkout of the code that ships. So "update and move on" is the wrong response here.

Why did the SSH backdoor fail on most machines?

Mostly because the attacker wrote buggy code. BleepingComputer, citing analysis by Phorion, found one bug per platform:

• On macOS, the script runs systemsetup -getremotelogin without admin rights. That returns a permissions error instead of "Off," and the script only enables SSH when it sees "Off." So it never does.
• On Windows, it calls PowerShell through /bin/sh to install OpenSSH Server. Normal Windows machines don't have /bin/sh, so that fails too.

Cursor gives a related reason. Turning on SSH needs admin rights the extension usually doesn't have, so on most machines the attacker "could not have logged in through the tunnel."

I wouldn't treat that as a clean bill of health. The key, the persistence and the beacon still landed. A machine that already had SSH on, or ran Cursor as admin, is in a different position. And an attacker who knows which machines checked in can come back with a version that works.

How did a fake build get into Cursor's marketplace?

As of October 30, 2026, nobody has said. Cursor confirmed the build wasn't Anthropic's and took the marketplace down to audit access and rotate keys. Neither company has explained how a build under Anthropic's extension ID got published there.

The confusion on day one shows how split up extension distribution is. A VS Code-style extension can come from three places:

Registry	Who runs it	Used by
Visual Studio Marketplace	Microsoft	VS Code (Microsoft's terms limit it to its own products)
Open VSX	Eclipse Foundation	VSCodium and many VS Code forks
Cursor's marketplace	Cursor	Cursor

Open VSX and Microsoft's Visual Studio Marketplace were not affected by the October 29, 2026 Claude Code extension compromise. Early reports said they were hit too, and later reporting corrected that: Cursor's marketplace was the only source. The same extension ID was clean in two registries and malicious in the third, and the editor a developer happened to use decided which one they got.

How do I check if I installed the malicious Claude Code extension?

Check every machine that ran Cursor on October 29 or 30.

Indicator	Where to look
SSH key with comment svc-telemetry	~/.ssh/authorized_keys (macOS/Linux); %USERPROFILE%\.ssh\authorized_keys and C:\ProgramData\ssh\administrators_authorized_keys (Windows)
Extension folder anthropic.claude-code-2.1.312-* or -2.1.313-*	~/.cursor/extensions or %USERPROFILE%\.cursor\extensions (may be gone after auto-update)
macOS LaunchAgent	~/Library/LaunchAgents/com.apple.sysmond.plist
macOS/Linux files	~/.config/.smt, ~/.config/.smtk, $TMPDIR/.stk_* or /tmp/.stk_*
Linux cron	@reboot /bin/sh "$HOME/.config/.smt"
Windows persistence	Scheduled task SysMon; sysmon.cmd in the Startup folder; %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_*
Network	134.209.82[.]225 on TCP 22 (tunnel) and 8099 (beacon)
Processes	ssh -N -R '*:0:localhost:22', autossh -M 0

The quickest check on a Mac:

grep -s svc-telemetry ~/.ssh/authorized_keys

Cursor's notice has the file hashes, key fingerprints and remediation scripts for macOS and Windows.

Does uninstalling the Claude Code extension remove the backdoor?

No. Uninstalling the malicious Claude Code extension from Cursor, or updating to 2.1.314, removes the loader but does not remove the SSH backdoor. The svc-telemetry key remains in authorized_keys, and the persistence scripts can run without Cursor. The LaunchAgent, the scheduled task, the cron entry and the retry scripts keep running until someone removes them.

If a machine shows any of the indicators above:

1. Take it off the network.
2. Save the evidence (the files above, plus shell and auth logs) before changing anything.
3. Remove the key, the persistence and any tunnel processes with Cursor's scripts, or rebuild the machine. If you can't prove the tunnel never connected, rebuild.
4. From a machine you trust, rotate every credential the affected machine could reach: cloud keys, GitHub and CI tokens, SSH keys, API keys and live sessions. The attacker has the variable names, so start with those.
5. Reinstall Claude Code 2.1.314 or later once the machine is clean.

Why didn't AI agent guardrails catch it?

The tampered code never asked Claude to do anything. It ran in the editor's extension host before any agent session started, so it never touched a tool call, a hook or a prompt. Prompt filters, tool-call policies and approval dialogs weren't in the way.

We build runtime controls at Unbound, and I still think they matter, for the things agents actually do: running a destructive command, pasting a secret into an MCP call. This attack just came in through a different door: it was an IDE extension supply chain attack. In an IDE extension supply chain attack, the attacker tampers with an extension somewhere between its author and the developer's editor, so trusted-looking code runs with the developer's permissions. A coding agent is software, and it reaches the laptop through a supply chain that has gotten long:

• the editor (Cursor, VS Code, Windsurf, JetBrains)
• the editor's marketplace, which may not be the one the publisher runs
• the agent extension
• whatever the agent loads after that: plugins, hooks, MCP servers, skills and rules, often installed with one line copied from a README

All of it runs with the developer's access, and almost none of it went through a security review. Developers install these tools themselves because they're useful and installing them takes ten seconds. I do it too. That's what shadow AI looks like on a real fleet: a long tail of privileged code on the machines that hold your keys.

"Only install the official extension" stops being a policy when the same extension ID can mean different code depending on which marketplace served it.

How do you inventory IDE extensions on developer machines?

Read each editor's extension registry on every developer machine and record the machine, editor, extension ID and installed version. For this incident, that means finding anthropic.claude-code 2.1.312 or 2.1.313 in Cursor, then checking those machines for persistence even if the extension has since updated. Put coding agents, plugins, hooks and MCP servers in the same inventory. Without one, "who installed 2.1.313?" turns into a fleet-wide script and a week of Slack messages.

Treat a new hook, plugin or MCP server as a change worth reviewing, the way you'd review a new dependency.

Cut down what a compromised laptop can reach. Short-lived, scoped credentials beat long-lived keys sitting in .zshrc and .env files.

Consider a short soak period for agent extension updates on high-privilege machines. Auto-update is how a tampered build reaches people who never clicked anything.

How does Unbound help with AI coding agent supply chain risk?

Unbound is an Agent Access Security Broker (AASB): it discovers the AI coding agents running across a company's developer machines, assesses their risk, and enforces policy on what they do.

To be clear, Unbound would not have stopped this loader. It never went through the agent, and nothing on the agent's path could have seen it.

Where Unbound helps is the next hour. Unbound discovery inventories the coding agents on each managed machine, including the Claude Code extension inside Cursor, VS Code and Windsurf, with the version in use, read from the editor's own extension registry. When an incident like this lands, the list of machines to check for the svc-telemetry key is already there, and any machine still on 2.1.312 or 2.1.313 shows up by version.

The same inventory covers the hooks, plugins, MCP servers, skills and rules each agent loads. Hooks get a risk score, so a new one that phones home or reads credentials doesn't hide in a dotfile.

For the actions agents do take (shell commands, file edits, MCP calls), Unbound can audit, warn, require approval or block, across Claude Code, Cursor, Codex and GitHub Copilot.

This won't be the last tampered extension. Marketplaces, mirrors and one-line installers are how code gets onto developer laptops now, and knowing what's installed where is the part you can set up before the next one.

Get a free risk assessment. See which coding agents, extensions, hooks and MCP servers are running across your developer fleet at getunbound.ai/risk-assessment.

Book a demo. Walk through discovery and policy on your own environment at getunbound.ai/book-demo.

Frequently Asked Questions

Which Claude Code extension versions were malicious? Cursor lists Claude Code extension (anthropic.claude-code) versions 2.1.312 and 2.1.313 for macOS and Windows, as distributed by Cursor's marketplace on October 29, 2026. Anthropic did not build them. Anthropic has since published a clean version, 2.1.314.

Was the Claude Code extension on the VS Code Marketplace or Open VSX affected? No. Early reports named Open VSX and Microsoft's Visual Studio Marketplace, but later reporting confirmed that Cursor's marketplace was the only source of the tampered builds. BleepingComputer reports that the Claude Code npm package was not affected either.

How many users were affected by the Cursor Claude Code extension compromise? Cursor has said up to 5,000 users may have installed or auto-updated to a tampered build during the roughly 11-hour window on October 29, 2026. Cursor says it is contacting affected users directly.

What is the svc-telemetry SSH key? svc-telemetry is the comment on the attacker's ed25519 public key that the malicious Claude Code extension added to ~/.ssh/authorized_keys. Finding svc-telemetry in an authorized_keys file means the payload ran on that machine. On macOS or Linux, run grep -s svc-telemetry ~/.ssh/authorized_keys to check.

Does updating to Claude Code 2.1.314 remove the backdoor? No. Updating replaces the extension but leaves the SSH key, the LaunchAgent or scheduled task, and the retry scripts in place. Use Cursor's remediation scripts or rebuild the machine, then rotate credentials from a trusted device.

Did the attacker get SSH access to affected machines? On most machines, probably not. Bugs in the payload and missing admin rights stopped it from turning on the SSH server on most macOS and Windows hosts. The key, persistence and data beacon still installed, so machines that already had SSH enabled or ran Cursor as administrator are at higher risk.

What data did the malicious Claude Code extension steal? It sent the hostname, username, OS, home and working directories, Git email, public IP, and the names (not values) of up to 40 environment variables containing terms like KEY, TOKEN and SECRET to 134.209.82[.]225. Those names show an attacker which clouds and services the machine can reach.

How did the tampered build get into Cursor's marketplace? As of October 30, 2026, neither Cursor nor Anthropic has said publicly. Cursor confirmed the build was not developed by Anthropic, took its marketplace offline, audited access and rotated keys before bringing it back.

Are Cursor extensions safe to install? In the October 29, 2026 incident, Cursor reported finding no other tampered extensions. The broader lesson applies to every editor: extensions, plugins, hooks and MCP servers run with the developer's full access, so companies should keep an inventory with versions and review new ones before they spread.

---

Related reading

• Securing Cursor, Codex, and Claude Code: A Comparison of AI Coding Agent Risks
• Shadow AI Coding Agents: The Security Risk Your Engineering Team Isn't Talking About
• Your Team Adopted Cursor. Do You Know Which MCP Servers It Can Reach?
• What is an Agent Access Security Broker (AASB)?

---

References: Cursor's security notice on the malicious Anthropic.claude-code extension, The Hacker News and BleepingComputer.