Attack vector could have handed over the whole extension market

An Israeli security outfit has revealed that an error buried deep in the automation scripts of the Open VSX Registry might have let criminals hijack every Visual Studio Code extension distributed through the popular open-source marketplace. Had the weakness been abused, any developer who installs or silently updates an extension that relies on Open VSX—including those working inside cloud IDEs such as Gitpod or Google Cloud Shell—could have received poisoned updates able to run code on their machines.

Oren Yomtov of Koi Security says the discovery means “millions of developers were one click away from compromise.” His team realised that the registry’s continuous-integration routine, which publishes community extensions around 03:03 UTC each morning, executed untrusted build scripts while holding a powerful secret: the OVSX_PAT token for the official @open-vsx service account. That credential can overwrite any listing in the catalogue. In simple terms, a malicious contributor could have slipped a script into an apparently innocent pull request and, once the workflow ran, stolen the token and republished every extension with hidden backdoors.

How the exploit unfolded

Maintainers encourage package authors to ask for automatic publication by adding their project to an extensions.json file in the public publish-extensions repository. After a maintainer approves the change, GitHub Actions kicks in, calling the vsce command-line tool to push each listed extension to the registry. While that seems convenient, the workflow naïvely performs npm install on every package and its dependencies—a step that, by design, runs any build or post-install script the package author wrote. Because the token lives in the job’s environment variables, those scripts can simply print it or exfiltrate it to a remote server.

With that token in hand, an attacker would have enjoyed the same rights as a registry administrator: they could upload a brand-new extension, replace the contents of trusted favourites, or delete listings altogether. Because many IDEs fetch updates automatically in the background, compromised code could have spread within hours, giving adversaries a beachhead inside corporate networks that rely on Visual Studio Code for development.

Patching the hole

Koi Security privately reported the problem to the Eclipse Foundation—custodian of Open VSX—on 4 May 2025. According to the timeline the researchers shared, maintainers issued several interim fixes before shipping a definitive update on 25 June. The final patch changes the workflow so that untrusted code never sees the secret token: it isolates the publish step, skips unnecessary installs, and uses Open VSX’s fine-grained permission model to prevent blanket overwrite rights.

The Eclipse Foundation thanked the researchers in a brief advisory and urged all contributors to review their own extension pipelines for similar pitfalls. “We appreciate responsible disclosure and have implemented additional hardening to safeguard the community,” the statement read. No evidence has surfaced that anyone exploited the bug before the fix.

A broader wake-up call for IDE marketplaces

Although package managers like npm and PyPI regularly dominate headlines about software-supply-chain risk, integrated-development-environment extensions have flown under the radar. That may be changing. In April 2025 the MITRE ATT&CK framework introduced a new technique called “IDE Extensions,” warning that rogue add-ons can grant persistent access on developer workstations—prime targets because they often hold proprietary source code and deployment secrets.

Yomtov argues that the incident shows just how thin the line is between convenience and catastrophe. Every extension, he notes, is “a potential back door.” Unlike classic operating-system packages, IDE add-ons usually run with the same rights as the user and can intercept source files, credentials, and even terminal sessions. Because developers tend to install them by the dozen, the attack surface quickly balloons.

What developers should do now

Security professionals suggest locking down extension workflows by setting least-privilege tokens, turning off automatic updates where feasible, and vetting third-party code with the same scrutiny applied to other dependencies. Organisations with stringent requirements may want to mirror trusted versions of critical extensions in an internal registry and review diffs before accepting updates.

Most importantly, researchers say, development teams must understand that supply-chain threats no longer stop at libraries and containers. From the editor themes that colour the screen to the linters that run on every save, any component that arrives through a marketplace is a potential delivery vehicle for malware. The swift remediation of the Open VSX flaw closed one door, but it also underscored the need for continuous vigilance across the entire development ecosystem.