The compromised Claude Code extension: who can publish to your laptop?

Picture a developer on October 29. They open Cursor. Claude Code has updated itself, like it often does. Nothing looks different.

But this update didn’t come from Anthropic. The Hacker News Cursor

Their company probably has rules for this laptop: who gets admin rights, which tools are allowed, who reviews the requests.

Yet that morning, new code arrived and ran without any new approval. Up to 5,000 Cursor users may have been exposed through the same trusted channel. The Hacker News

How is that possible? Let’s reconstruct it.

What happened

Two versions were tampered with, 2.1.312 and 2.1.313. Both were the real extension plus about 7 KB of extra code, which ran as soon as the extension loaded. StepSecurity Cursor

October 29, 2026 (UTC)

00:0006:0012:0018:0024:00 09:27
bad builds live 20:35
pulled 11 hours · up to 5,000 users exposed

The code added the attacker’s SSH key, survived reboots and sent home details about the machine. Phorion StepSecurity It also tried to open a remote access tunnel. On most machines that step failed: it needed admin rights, and the attacker’s code had bugs. Cursor Keep that in mind.

Cursor has since taken the attacker’s server offline and found no other tampered extensions. Cursor

Then came the statements. Anthropic says it wasn’t breached. The Register Cursor hasn’t said how the build got in. Cursor

Our developer did nothing unusual. So where did the code come in?

Following the code

Our developer trusted one name: “Claude Code by Anthropic”. But the code passes through several hands before it reaches you, and each one holds keys.

Where your trust actually goes

1. You trustAnthropicwrites the code
2. Weak linkRelease pipelinebuilds it
3. Weak linkPublisher accountuploads it
4. Weak linkMarketplaceserves it
5.  Auto-updateinstalls it
6. TargetYour laptopruns it as you

Cursor confirms the bad builds came from its marketplace. How the attacker got access is still unknown publicly. Cursor

A store signature doesn’t solve the provenance problem either. Where a store signs extensions, as Open VSX does, the signature proves the file wasn’t changed after the store signed it. Open VSX It doesn’t prove who wrote it.

Then auto-update delivered it to our developer’s laptop and ran it with their rights. No one had to approve this version.

One approval, every update

Now think about how that laptop is governed. Here is what I’ve seen in the field:

• Developers need flexibility. They rely on custom tools and extensions, and sometimes get admin rights or relaxed security settings to do their work.
• The business needs speed. Waiting for every tool to be approved slows teams down.
• Security sets boundaries. Admin rights, endpoint controls and exceptions get discussed, sometimes after the fact.

So admin rights get debated, and exceptions get reviewed. But another decision rarely gets the same attention: who approved the extension, and the channel that keeps updating it?

Maybe someone approved it once. Maybe the marketplace was simply allowed. Either way, new versions keep arriving without another internal review, and they run with the user’s own rights, even without local admin privileges.

One decision to trust the channel can mean trusting every update it delivers. You can manage admin rights well and still not govern the code that updates itself on your laptops.

We reviewed the developer’s access. Did we ever review the publisher’s?

In identity governance, we expect powerful access to have three things:

• an owner
• a reason
• a review date

The publisher may well govern its own release rights. The gap is on our side: we may have approved the publisher once, without ever revisiting what that trust allows.

We can’t govern their side. We can govern our decision to trust the publisher, the store and the update channel. That decision needs the same three things.

Who approved that marketplace? IAM, endpoint, application security, or the developers themselves? If nobody can answer, nobody owns the risk.

Admin rights still matter. This time, bugs in the attacker’s code stopped the tunnel almost everywhere. It only stood a chance where Cursor ran with admin rights. Cursor I wouldn’t count on the next attacker making the same mistakes.

But they were never the whole story. The payload could add an SSH key, set up persistence and send host details without them. Cursor Removing admin rights limits the damage. It doesn’t prevent the code from running.

This keeps happening, too. Extension stores and release channels have been hit several times this year. CSA BleepingComputer BleepingComputer

What I’d do this week

So make that decision on purpose. Three goals, each with a cost:

1. Decide who you trust. First, find out which extensions, marketplaces and publishers your developers actually use. Then decide which are approved, and who owns that decision. The cost: visibility takes effort, and new tools may take longer to arrive.
2. Don’t take every update on day one. Where your tools let you hold updates back, roll them out in rings, with a fast lane for security fixes. The bad builds lived 11 hours. Cursor The cost: some fixes arrive later too.
3. Limit the blast radius. Keep admin rights the exception, keep production credentials off laptops, and alert on new SSH keys: each one is a new way into an account. The cost: more friction for developers.

If you publish software:

1. Name who can publish, and review that list like an admin group.
2. Publish from CI with short-lived tokens, not from a laptop.
3. Ask for a second approver. A few minutes of review, versus a backdoor under your name.

If you think you were affected

Uninstalling the extension alone is not enough: the backdoor keeps running on its own. Cursor The tampered builds were for macOS and Windows. StepSecurity On a Mac, start with this:

grep svc-telemetry ~/.ssh/authorized_keys

This check alone isn’t conclusive. If it prints anything, if you’re on Windows, or if you installed one of the two versions, follow Cursor’s full procedure: isolate the machine, remove the key and the persistence, and rotate the credentials it could reach. Cursor

For your security team, here are the main indicators of compromise (IoCs). Cursor StepSecurity Phorion

Type	Indicator
Extension	anthropic.claude-code 2.1.312 and 2.1.313, from Cursor’s marketplace
SSH key	comment svc-telemetry, fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk
Network	134.209.82[.]225, on TCP 22 (tunnel) and port 8099 (/beacon)
Files	~/.config/.smt, ~/.config/.smtk, .stk_ files in the temp folder
Persistence	macOS LaunchAgent com.apple.sysmond, Windows task SysMon (the code also has a Linux @reboot cron, but no Linux build was reported)
Payload	extension.js, SHA-256 ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15

Cursor’s notice has the full list, with Windows paths and file hashes.

Looking ahead

Back to our developer. They did nothing wrong. They trusted a name. Their company may have approved it once, effectively trusting every update that followed.

For a CISO, the question isn’t whether every update needs a manual approval. It’s this: who can send code to our machines, what rights does that code get, and who accepted that risk?

We often ask “who has admin rights?” Rarely “who can push code to all our laptops?” Ask it this week.