The original writeup identifies Open VSX — not Microsoft's Marketplace — as the attack surface because Cursor, Windsurf, VSCodium, and other forks default to it and it is less heavily moderated. The researcher frames discovery as reactive: a public writeup forced the takedown, which is the same pattern that repeats every time.
Argues extension marketplaces are the softest supply-chain surface in a modern developer's stack and that the proliferation of VS Code forks has made it softer. Unlike npm, which has Socket, Snyk, and GitHub advisories watching, Open VSX relies on individual researchers to surface malicious packages.
Points out that Anthropic distributes Claude Code's VS Code extension only through Microsoft's Marketplace, leaving no official listing on Open VSX. That vacuum is precisely what the attacker filled — a Cursor user searching 'Claude Code' sees Open VSX results and reasonably assumes one is legitimate.
Argues the 'verified publisher' badge on Open VSX does not carry the same guarantees as on Microsoft's Marketplace, which ties publishers to domains via DNS verification. Developers who rely on the badge as a trust signal are importing assumptions from a different registry.
The writeup emphasizes that the malicious code was ordinary post-install JavaScript — nothing exotic — but it ran inside the extension host with the same filesystem and network reach as every other extension installed. The ordinariness is the point: any extension you trust implicitly inherits that same reach.
A VS Code–compatible extension published to the Open VSX registry under a name designed to look like the official Claude Code integration was identified as malicious and taken down after a public writeup on phorion.io. The payload wasn't a novelty — it was the usual post-install JavaScript running inside the editor's extension host, which means it ran with the same filesystem and network reach as every other extension you have installed.
The target wasn't Microsoft's VS Code Marketplace. It was Open VSX — the Eclipse Foundation–run registry that Cursor, Windsurf, VSCodium, Gitpod, Theia, and most non-Microsoft VS Code forks point to by default. Those forks can't legally use Microsoft's Marketplace, so Open VSX is the de facto second ecosystem for anyone not running vanilla VS Code. It is also, by design and by resourcing, less heavily moderated.
Anthropic ships Claude Code primarily as a CLI with an official VS Code extension distributed through Microsoft's Marketplace. There is no Anthropic-published Claude Code extension on Open VSX today — which is precisely the gap the attacker filled. A developer in Cursor searching "Claude Code" sees results from Open VSX and reasonably assumes one of them is the real thing. One of them, briefly, wasn't.
Extension marketplaces are the softest supply-chain surface in a modern developer's stack, and the fork ecosystem has made it softer. On npm you at least have Socket, Snyk, and GitHub's own advisory database watching. On Open VSX, discovery of malicious packages still leans heavily on individual researchers posting writeups and the registry reacting. The pattern this time — researcher publishes, registry pulls, downstream editors catch up whenever — is the pattern every time.
The thing worth internalizing is that "verified publisher" on Open VSX does not mean what "verified" means on the Microsoft Marketplace. Microsoft's verification ties a publisher to a domain via DNS and gates the blue checkmark behind that. Open VSX's namespace model is more permissive: namespaces can be claimed, verification is opt-in, and the registry has historically been slow to resolve disputes when a legitimate project hasn't bothered to claim its name. If the real vendor hasn't shown up on Open VSX, the name is effectively unowned and a lookalike can plausibly occupy it.
Compounding this: Cursor and the other forks don't surface the distinction. The install UI looks the same whether a package came from a verified publisher, an unverified namespace, or a user who registered the name last week. The social proof signals developers actually read — install count, star count, publish date — are all trivially gameable in the first days after a package appears, which is exactly when a typosquat is most dangerous.
The asymmetry here is brutal. Anthropic can ship the perfect CLI, sign every release, enforce SLSA provenance on their own build pipeline, and none of it helps a Cursor user who installs the wrong extension because the right one doesn't exist in their registry. The attack surface isn't the vendor's security posture — it's the vendor's absence from a registry the vendor doesn't officially support.
Community reaction on the Hacker News thread (370 points) split predictably. One camp blamed Open VSX for lax moderation. Another pointed at Anthropic for not claiming the namespace defensively, the way serious npm maintainers now squat their own typo variants. A third — the most useful one — pointed out that this is structurally the same problem as pip, npm, Chrome Web Store, and the Firefox Add-ons gallery have all had, and that "the registry should fix it" is a slogan, not a plan. Registries at this scale cannot manually review every submission; the economics don't work.
If you use Cursor, Windsurf, VSCodium, or any VS Code fork, open your extensions panel right now and look at anything named Claude, Claude Code, or Anthropic. Check the publisher namespace, the GitHub repo link, the publish date, and the install count — in that order — before you trust it to run inside your editor's process. If the repo link is missing, broken, or points to a profile with no other activity, uninstall it. If you can't tell whether an extension is real, the correct move is to use Anthropic's official CLI directly from a terminal and skip the editor integration entirely until the vendor publishes officially.
For teams, this is a policy problem, not a tooling problem. Treat IDE extensions the same way you treat npm packages in a locked-down environment: pin to known publishers, maintain an allowlist, and route installs through a review process for anything new. The extension host has access to your working directory, your shell environment, your SSH agent socket if it's forwarded, and whatever credentials your editor has cached. A compromised extension is a compromised dev workstation. If your threat model takes npm supply chain seriously, your threat model has to take VSX supply chain exactly as seriously — and most don't.
If you're a vendor shipping developer tools, the lesson is defensive registration. Claim your name on every registry a user might plausibly search, even ones you don't officially support. A stub extension that says "the official version lives at X" is cheap insurance and prevents exactly this scenario. The attacker's leverage was the empty namespace. Fill it.
Expect more of these. The AI coding tool boom has created dozens of vendor names developers want to install into their editors, and the fork ecosystem has created a parallel registry with a fraction of the moderation budget. Until Open VSX ships stronger publisher verification by default — or until the forks start surfacing provenance in the install UI — the pattern will repeat. The practical defense isn't waiting for infrastructure; it's treating every extension install like `curl | sh` and acting accordingly.
This is from the Cursor blog [1] linked in the description, but repeating it here in case it's useful to anyone:------Check whether you are impactedThe malicious extension appends the attacker's public key, labeled svc-telemetry, to your SSH authorized keys. To check for it:On macOS, run:
https://www.reuters.com/business/media-telecom/cursor-says-u...> Cursor said the extension was not developed by Anthropic and the maliciously modified extension was live on the marketplace from about 2:27 a.m. PT to 1:35 p.m. PT on ThursdaySo is this or isn't this fr
The original Phorion report really should be up here. It even details what exactly happened. So they simply added a ssh key to the authorized keys.https://phorion.io/blog/offical-claude-code-vsx-compromise/
I think it should be important to note that this affected the Claude Code extension on the Open VSX extension registry (and by extension, the Cursor marketplace). From what is currently known, the build on the official marketplace was/is clean.EDIT: I am now actually unsure if this is the case.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Felix from Anthropic here.We’re working with Cursor on this incident, but it wasn’t a compromise of Anthropic’s systems or employee laptops. A malicious actor used access to Cursor’s marketplace to publish a tampered copy of the Claude Code extension, which we didn’t build or publish. The versions o