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

Anas Sahel · 30 October 2026 · https://anassahel.com/en/blog/who-signed-this/

Tags: identity, supply chain, ai

- On October 29, malicious versions of the Claude Code extension were served through Cursor's marketplace, potentially exposing up to 5,000 users through installation or auto-update.
- The malware was ordinary. The way it arrived was not: under a name everyone already trusted.
- The question it leaves: who, in your company, decided to trust that update?

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](https://thehackernews.com/2026/10/official-claude-code-vs-code-extension.html) [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)

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](https://thehackernews.com/2026/10/official-claude-code-vs-code-extension.html)

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](https://www.stepsecurity.io/blog/claude-code-extension-trojanized) [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)

*[Figure: October 29, 2026 (UTC). The tampered versions were served for about 11 hours. Auto-update installed them without anyone clicking. [Cursor](https://cursor.com/blog/claude-code-extension-security-notice) [StepSecurity](https://www.stepsecurity.io/blog/claude-code-extension-trojanized)]*

The code added the attacker's SSH key, survived reboots and sent home details about the machine. [Phorion](https://phorion.io/blog/offical-claude-code-vsx-compromise/) [StepSecurity](https://www.stepsecurity.io/blog/claude-code-extension-trojanized) 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](https://cursor.com/blog/claude-code-extension-security-notice) Keep that in mind.

Cursor has since taken the attacker's server offline and found no other tampered extensions. [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)

Then came the statements. Anthropic says it wasn't breached. [The Register](https://www.theregister.com/cyber-crime/2026/10/30/anthropic-that-claude-code-extension-compromise-couldnt-be-us/5306682) Cursor hasn't said how the build got in. [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)

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.

*[Figure: Where your trust actually goes. You trust the first box. An attacker only needs one of the three red ones. Whichever they pick, the target is the same: your laptop. Which one was used here is still not confirmed.]*

Cursor confirms the bad builds came from its marketplace. How the attacker got access is still unknown publicly. [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)

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](https://github.com/eclipse/openvsx/pull/673) 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](https://cursor.com/blog/claude-code-extension-security-notice) 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](https://cursor.com/blog/claude-code-extension-security-notice) 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](https://labs.cloudsecurityalliance.org/research/csa-research-note-glassworm-v2-openvsx-ai-dev-supply-chain-2/) [BleepingComputer](https://www.bleepingcomputer.com/news/security/glassworm-malware-attacks-return-via-73-openvsx-sleeper-extensions/) [BleepingComputer](https://www.bleepingcomputer.com/news/security/ovhcloud-cli-releases-backdoored-on-github-to-steal-developer-secrets/)

## 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](https://cursor.com/blog/claude-code-extension-security-notice) 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](https://cursor.com/blog/claude-code-extension-security-notice) The tampered builds were for macOS and Windows. [StepSecurity](https://www.stepsecurity.io/blog/claude-code-extension-trojanized) On a Mac, start with this:

```sh
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](https://cursor.com/blog/claude-code-extension-security-notice)

For your security team, here are the main indicators of compromise (IoCs). [Cursor](https://cursor.com/blog/claude-code-extension-security-notice) [StepSecurity](https://www.stepsecurity.io/blog/claude-code-extension-trojanized) [Phorion](https://phorion.io/blog/offical-claude-code-vsx-compromise/)

| 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.

## Sources

1. [Cursor](https://cursor.com/blog/claude-code-extension-security-notice)
2. [The Register](https://www.theregister.com/cyber-crime/2026/10/30/anthropic-that-claude-code-extension-compromise-couldnt-be-us/5306682)
3. [Phorion](https://phorion.io/blog/offical-claude-code-vsx-compromise/)
4. [StepSecurity](https://www.stepsecurity.io/blog/claude-code-extension-trojanized)
5. [The Hacker News](https://thehackernews.com/2026/10/official-claude-code-vs-code-extension.html)
6. [Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-glassworm-v2-openvsx-ai-dev-supply-chain-2/)