Marketplace Takeover: How We Could’ve Taken Over Every Developer Using a VSCode Fork; Putting Millions at Risk

Oren Yomtov

June 26, 2025

TL;DR: We discovered a critical vulnerability in open-vsx.org, the open-source VS Code extensions marketplace powering popular VSCode forks like Cursor, Windsurf and VSCodium, used by over 10,000,000 developers. This vulnerability provides attackers full control over the entire extensions marketplace, and in turn, full control over millions of developer machines. By exploiting a CI issue a malicious actor could publish malicious updates to every extension on Open VSX. One bug. Full marketplace takeover. Millions of developers and their organizations — compromised. If you control the extensions, you control the machine, the code, and the business.

OpenVSX: Born from VS Code’s walled garden

Visual Studio Code’s success is mainly due to its ecosystem of extensions, but that ecosystem has a catch. Microsoft’s official marketplace comes with strings attached: only Microsoft’s own products are allowed to use it. The terms of use explicitly forbid non-Microsoft builds of VS Code from accessing the official extension marketplace. In other words, if you’re running a community build or fork of VS Code, you’re not legally allowed to pull extensions from Microsoft’s servers.

This restriction led to the creation of Open VSX, a vendor-neutral, open-source extension marketplace hosted by the Eclipse Foundation. Open VSX was envisioned as the community-driven alternative for VS Code forks and other open-source IDEs: a place where extensions could be shared without Microsoft’s gatekeeping. The Eclipse Foundation openly stated that without a community-driven alternative, the VS Code-only marketplace would “severely restrict the capabilities of organizations that have adopted open source developer tools.”

In practice, Open VSX functions almost exactly like the official VS Code Marketplace, but it’s open to any VS Code fork. Developers can publish extensions to Open VSX, and users of VS Code forks can install those extensions seamlessly. The project has been around since 2020, and has become the de facto app store for VSCode forks like Cursor, Windsurf, Gitpod, Coder and others.

So, who relies on Open VSX?

Over 10 million developers depend on Open VSX across dozens of VS Code based editors including Cursor, Windsurf, Google Cloud Shell Editor, and Gitlab Web IDE.

Open VSX was originally developed for the Eclipse Foundation’s VS Code fork Eclipse Theia (20k stars on Github), which in turn, powers a wide range of code editors. But practically every VSCode fork relies on open-vsx.org as their primary extensions marketplace.

Here’s a quick run down of just some of the code editors using it today:

Cursor: 1,000,000+ estimated users
Windsurf (formerly Codeium): 600,000+ estimated users
VSCodium: 27.3k stars, 300,000+ estimated users
Google Cloud Shell Editor: 100,000+ estimated users
GitLab Web IDE: 100,000+ estimated users
StackBlitz: 10.5k stars, 3,000,000+ estimated users
Gitpod: 13.3k stars, 1,500,000+ estimated users
code-server (aka Coder.com): 71.6k stars, 1,000,000+ estimated users
Arduino IDE 2.x: 2.6k stars, 1,000,000+ estimated users
Red Hat OpenShift Dev Spaces
SAP Business Application Studio
IBM Wazi Developer
Texas Instruments Code Composer Studio
Arm Mbed Studio
Acquia Cloud IDE
Eclipse Che4z

This widespread adoption means that a compromise of Open VSX is a supply-chain nightmare scenario. Every single time an extension is installed, or an extension update fetched silently in the background, these actions go through Open VSX.

And unfortunately, as we’ve uncovered, one simple bug put millions of developers at incredible risk in a magnitude previously unseen.

The Vulnerability: A Variation On The Classic “Pwn Request”

In May 2025, our research team identified a flaw in the publish-extensions repository, the mechanism that populates Open VSX with extensions.

If you want to publish an extension to Open VSX, you have two options:

Upload it to Open VSX yourself
Request an extension to be auto-published by creating a pull request that adds the extension to the list in the extensions.json file:

Here’s how Open VSX auto-publishing works in a nutshell: There’s a nightly GitHub Actions workflow in the publish-extensions repo that takes the list of extensions from extensions.json and automatically updates any that have new versions. This workflow runs with privileged credentials including a secret token ( OVSX_PAT) of the @open-vsx service account that has the power to publish (or overwrite) any extension in the marketplace. In theory, only trusted code should ever see that token.

The nightly workflow works roughly like this:

Clone the extension’s repository
If the version in package.json is newer than the current version:
Run npm install
Publish the newly built extension to open-vsx.org as the @open-vsx user using the authentication token in the OVSX_PAT environment variable

The root of the vulnerability is that npm install runs the arbitrary build scripts of all the auto-published extensions, and their dependencies, while providing them with access to the OVSX_PAT environment variable.

We verified that we could indeed exfiltrate OVSX_PAT by exploiting the vulnerable workflow design by using this example repository.

The Impact: A Supply-Chain Nightmare That Exposed Millions of Developers

Once you steal the @open-vsx account's token, you've basically stolen the keys to the kingdom. This token is a super-admin credential for the Open VSX Registry - it can publish new extensions, update or overwrite existing ones. From an attacker's perspective, that's control over an entire ecosystem's supply chain. The next time a developer's IDE auto-updates their extensions (or a user installs a new one), they'd silently receive the compromised payload.

What could an attacker do with that ability? In short, anything they want on your machine¹. Extensions in VS Code run as a Node.js process, so they can spawn processes, read/write files, make network requests and basically act as malware running under the user account. A malicious update to, say, the Python extension could quietly insert keyloggers, steal cookie jars, source code, infect build artifacts, or implant backdoors in any developer’s project. It’s the SolarWinds scenario for developer tooling: compromise the update mechanism, and you’ve compromised all the downstream systems that consume those updates.

There have previously been incidents of individual malicious VS Code extensions doing things like stealing SSH and crypto wallet keys, but this could have magnified such an attack to a different order of magnitude.

[1]: That’s the case for editors of the desktop variety like Cursor, Windsurf and VSCodium. For web-based editors like Gitlab’s Web IDE and Stackblitz, the impact depends on the editor’s domain and consequences of compromising the projects it has access to.

What should I do about it?

The world of extensions, and any software consumed from a marketplace, app store, or registry, must be treated as untrusted by default. These are third-party tools, developed by individual publishers, running with significant privileges, often hidden in plain sight. Just like any software dependency, they must be discovered, assessed, monitored, and governed continuously.

That means:

Maintaining an Inventory: Know what is installed, across which machines, and who is using it.
Performing Risk Assessment: Treat each extension or marketplace item as potential attack surface. What’s its origin? Is it maintained? What permissions does it request? What does it actually do?
Enforce Policy and Control: Define what’s allowed, and enforce remediation actions when something drifts out of policy; whether that’s auto-removing risky plugins or alerting the right teams.
Continuous Monitoring: Extensions can update silently. Your governance shouldn’t be one-and-done. You need visibility and control over every update flow.

Our research team uncovers vulnerable and real-world malicious extensions every day in Open VSX, Microsoft’s own VSCode Marketplace, and even private enterprise marketplaces. The problem is universal: if it’s code, and it runs in your environment, it’s part of your attack surface.

Every marketplace item is a potential backdoor. They’re unvetted software dependencies with privileged access, and they deserve the same diligence as any package from PyPI, npm, Hugginface, or GitHub. If left unchecked, they create a sprawling, invisible supply chain that attackers are increasingly exploiting.

You should adopt a zero-trust model for all marketplace-delivered software, treating every app, extension, plugin, model, MCP, code package or container as untrusted until it’s discovered, analyzed, approved, and monitored.

This writeup was authored by the research team at Koi Security, with a healthy dose of paranoia and hope for a safer open-source ecosystem.

Amazingly, we’ve initially uncovered all of this just a couple of days after MITRE introduced its newest category: IDE Extensions, even further emphasizing the importance of securing this space.

For too long, the use of untrusted third-party code, often running with the highest privileges has flown under the radar for both enterprises and attackers. That era is ending. The tide is shifting.

We’ve built Koi to meet this moment; for practitioners and enterprises alike. Our platform helps discover, assess, and govern everything your teams pull from marketplaces like the Chrome Web Store, VSCode, Hugging Face, Homebrew, GitHub, and beyond.

Trusted by Fortune 50 organizations, BFSIs and some of the largest tech companies in the world, Koi automates the security processes needed to gain visibility, establish governance, and proactively reduce risk across this sprawling attack surface.

If you’re curious about our solution or ready to take action, book a demo or hit us up here 🤙

We’ve got some more surprises up our sleeve to come soon, stay tuned.