Extension marketplace supply chain attacks: How a trusted add-on can turn on you

An extension marketplace supply chain attack happens when someone gets a harmful add-on into the store where developers pick their tools, so it installs like any trusted one. The target is not the developer’s laptop directly. It is the trust placed in the store, the publisher name and the update button.

Anthropic described a case like this on Friday. Its statement says a malicious actor used access to Cursor’s marketplace to publish a “tampered” Claude Code extension that Anthropic did not build or publish. Our news report covers what is and is not known so far.

The fake house key problem

Think of a locksmith shop inside a large mall. You trust the shop, and you trust the mall to keep out impostors. Now someone slips a copy of the shop’s sign, with its name, onto an empty stall. Customers walk in because the name looks right, and nothing about the stall tells them the shop never opened it.

A marketplace works the same way. Developers search for a tool, see a familiar name and click install. The vendor’s own build process can be perfectly safe, yet a copy published through the store still reaches users under that name. That is the distinction Anthropic draws in its statement.

Why an extension can do so much harm

A code editor extension is not a small sandboxed widget. Microsoft’s Visual Studio Code documentation says extensions run in an extension host that “has the same permissions as VS Code itself.” An extension can read and write files, make network requests, run other programs and change workspace settings.

That power is the point. A language helper must read your code, and an AI coding assistant must run commands. But it also means a malicious extension can reach whatever the developer can: source code, environment variables and access keys stored on the machine. The same documentation page does not describe a sandbox for installed extensions.

Extensions also tend to start automatically when the editor opens, so a harmful one does not need the user to click anything after installing.

How attackers get into a marketplace

Researchers and companies have reported several routes, and they differ a lot:

• Plain malicious uploads. A publisher creates an add-on that looks useful and hides harmful code. Researcher Mazin Ahmed described, in a Black Hat MEA talk listing, a linter extension that passed Microsoft’s screening.
• Look-alike names. An attacker takes a name close to a popular tool, or an unclaimed name a store or editor already recommends. Trendyol Tech’s analysis, summarized by daily.dev, compared extension names across the Microsoft Marketplace and Open VSX and counted many names that could be squatted.
• Flaws in the publishing pipeline. Security firm Koi reported a weakness that could let an attacker push updates to existing extensions on Open VSX, according to a summary on cert.ug. This is a vendor-reported research claim, and the registry has since changed its safeguards.
• Stolen or misused access. Someone who controls a publisher account or a marketplace login can publish as that publisher. Anthropic’s statement says a malicious actor used access to Cursor’s marketplace, but how that access was obtained has not been stated.

From the Solidity theft to AI assistants

Open VSX is an open registry run by the Eclipse Foundation. Many editors built on the VS Code codebase, such as Cursor, use it because Microsoft’s own marketplace has terms that limit its use to Microsoft’s products. Snyk’s July 2025 write-up of a $500,000 cryptocurrency theft is a well-known example. A developer using Cursor installed a fake Solidity language extension from Open VSX. Snyk reported more than 50,000 downloads before removal on July 2 and a PowerShell script that continued the theft. The download count in such cases can be inflated, so it is not proof of that many victims.

AI coding tools raise the stakes. An assistant extension often holds access to a model account, reads a whole repository and can run commands. A fake copy in that position can see more than a fake color theme could.

The problem is also not limited to editors. Package registries for code libraries, such as npm, face the same pattern. One case earlier this year involved the Claude Code npm package. The Hacker News reported that Anthropic confirmed an inadvertent release of internal code, after which attackers used fake repositories claiming to host the leak to spread malware. That was a separate event with a different cause.

What marketplaces and developers do about it

Marketplaces use several layers of defense. Microsoft’s documentation says its Marketplace scans each new extension and update with multiple antivirus engines, runs a clean room virtual machine check, signs packages on publication and checks the signature on install. It lists verified publishers, which have proven ownership of a domain name, and a block list that makes VS Code uninstall extensions found to be malicious. Since VS Code 1.97, the editor also asks users to trust a publisher before installing from a third party.

Other registries have fewer resources and fewer checks. Reports about Open VSX describe the Eclipse Foundation tightening its safeguards after researchers disclosed problems. Cursor’s forum shows users asking about the safety of its marketplace, but the page we read did not include an official answer.

For developers and teams, the advice repeated across these sources is practical:

• Check the publisher name and the extension identifier, not only the title and icon.
• Treat install counts and ratings as weak signals, since they can be manipulated.
• Keep a short approved list of extensions in company settings. VS Code documents an allowed extensions setting for organizations.
• Delay automatic updates for critical tools, so a bad update has time to be caught.
• Keep access keys out of files and environment variables where an extension could read them, and rotate any key if an extension is later reported as tampered.

The limits of every defense, and what to watch

Each defense has gaps. Scanning finds known patterns, not every new trick; Ahmed’s reported bypass used behavior that avoided Microsoft’s test environment. Verified publisher badges prove domain ownership, not good intent. Signatures show a package was not changed after publication, but they cannot show that the publisher is who the user thinks it is, especially if the attacker controls the marketplace itself.

That last case is the hardest one. When the store’s own systems are the entry point, the vendor’s build pipeline cannot protect users. The vendor can only publish clear notices and checkable details, such as official version numbers and identifiers.

Several things are worth watching. First, whether Cursor and Anthropic publish technical details of the tampered copy, which are still unknown. Second, whether editors that use open registries add stronger publisher checks or sandboxing. Third, whether AI assistant makers start offering a single verified channel for their extensions, so users have one place to compare against.