Claude Code Extension Trojanized on Cursor Marketplace

Was Anthropic breached? That's the question lighting up every security Slack this morning, and the answer, as far as anyone can show, is no. What actually happened is in some ways worse for the rest of us: someone pushed a trojanized update to Anthropic's official Claude Code extension through Cursor's own marketplace, under Anthropic's real publisher identity, and up to 5,000 developers installed it. No Anthropic compromise required. The trust model did the attacker's work for free.

The malicious build, version 2.1.313, carried a persistent SSH backdoor targeting Windows, macOS, and Linux. According to The Hacker News, it sat in the Cursor Marketplace for roughly 11 hours on October 29 — from about 2:27 a.m. to 1:35 p.m. PT — before Cursor shut the whole marketplace down to pull it. Anthropic has since published a clean 2.1.314 to Open VSX and Microsoft's VS Code Marketplace, neither of which is known to have been affected.

It wasn't Anthropic's breach. That's not the reassurance it sounds like.

Anthropic moved fast to draw the line. Felix Rieseberg, a member of its technical staff, said the company is working with Cursor but that this "wasn't a compromise of Anthropic's systems or employee laptops," adding that a malicious actor used access to Cursor's marketplace to publish a tampered copy Anthropic didn't build, The Register reports. Cursor, for its part, said the malicious version "was not developed by Anthropic" and that at most 5,000 users were affected.

Fine. But here's the part that should bother you more than the attribution question: the attackers didn't need a fake extension. They shipped the malware as version 2.1.313 under the legitimate extension ID, anthropic.claude-code. Jenn Gile, co-founder of OpenSourceMalware, told The Hacker News the package's main JavaScript bundle had a 66-line malicious loader inserted before the legitimate code. Every control a developer might apply — check the publisher, check the name, check it's the official one — would have passed. That's not a Cursor problem or an Anthropic problem. That's the marketplace model telling you what it's worth.

How the attacker got publish access remains unknown. Neither Cursor nor Anthropic has explained it. Cursor says it removed the package on detection, shut the marketplace "out of an abundance of caution," checked other extensions, rotated its own keys, and worked with a cloud provider to block the attacker's server. All sensible. None of it answers how the door was open in the first place.

What the implant actually did — and where it fell short

The payload was a proper backdoor, not a smash-and-grab stealer. On activation — after VS Code startup and when the extension's webview opens — it added an attacker-controlled key to the victim's ~/.ssh/authorized_keys, helpfully labeled svc-telemetry to look boring. It then tried to enable SSH access across all three desktop platforms, opened a reverse tunnel to 134.209.82[.]225, installed persistence as a scheduled task, crontab entry, or LaunchAgent depending on the OS, and beaconed host reconnaissance to 134.209.82[.]225:8099/beacon over unencrypted HTTP.

Now for the part that matters less than the headlines suggest. Enabling the SSH service requires admin rights, which the extension didn't have on most macOS and Windows hosts — Cursor's own analysis concedes the tunnel step failed there. So the cinematic outcome, an attacker walking straight into five thousand dev machines, mostly didn't happen. But "mostly" is doing heavy lifting. The implant still planted the key, installed persistence, and phoned home everywhere it ran, and Linux desktops with SSH already enabled are a different story. Cursor's advice is blunt: follow the remediation steps regardless. And note this — installing the fixed 2.1.314 does not remove the persistence. If you auto-updated through the bad window, you have cleaning to do, not updating.

The recon list tells you what the operator was shopping for:

• Public IP address (via api.ipify[.]org), hostname, and local username
• Operating system and CPU architecture, home directory, working directory
• Global Git email from git config --global user.email
• Names of up to 40 environment variables containing KEY, TOKEN, SECRET, PASS, AWS, or GCP

Security researcher Paul McCarty noted the variable values weren't sent in the initial beacon — but the names alone map out which cloud providers and CI systems a victim touches, and successful SSH access would let the operator read the values directly. Developer machines are credential piñatas. Everyone in this trade knows it; attackers budget for it.

Five thousand developers, eleven hours, one auto-update setting

Let's do the opportunity-cost arithmetic, because that's what your board will eventually ask about. Eleven hours of exposure. At most 5,000 installs, per Cursor. Gile's observation is the kicker: anyone with the extension set to auto-update could have consumed the malware the moment it landed. Auto-update is the default posture in most developer environments because we decided, collectively, that friction costs more than risk. Yesterday that invoice came due.

And it's not an isolated invoice. A little over a week earlier, an unknown attacker swapped the release binaries of five published versions of OVHcloud's official CLI with secret-stealing malware, uploaded through the hijacked GitHub account of a legitimate OVH contributor — an account taken in March as part of the GlassWorm operation. We've covered the same pattern from the other direction: LiteLLM 1.107.0 was backdoored through stolen GitHub tokens, and AI coding agents can be turned by a single file in a Downloads folder. The AI tooling supply chain isn't being targeted because it's trendy. It's being targeted because developers run it with broad credentials, on machines that can reach everything, and they update it without looking.

The fix costs less than the incident

Here's my call, and it's the unfashionable one: this incident was survivable, but the class of incident isn't. The attacker fumbled the privilege escalation, Cursor pulled the package fast, and the blast radius stayed in the low thousands. Next time the loader checks for an SSH service that's already running, or the window stays open a weekend. You cannot control any of that. What you can control is whether your developers' tooling updates itself from a registry you don't operate, under an identity anyone with the right access can wear.

The remediation for the affected is defined: isolate the hosts, strip the unauthorized SSH key and the persistence mechanisms, rotate credentials and sessions. For everyone else, the cheaper control is the one you've been postponing: pin extension versions, vet updates before they roll out, and treat developer workstations as the credential-bearing, production-adjacent assets they are. The question for your next board meeting isn't whether Anthropic was breached. It's why an unsigned-by-you binary can still land on a machine that holds your cloud keys. Answer that before someone else does.