The Open VSX Registry is acknowledging that post-publication takedowns are no longer enough to combat mounting supply chain threats in the open source extension ecosystem.

In a January 28 update, the Eclipse Foundation outlined a shift in how the registry approaches supply chain security, moving from a model that primarily reacts to reported malicious extensions toward one that enforces security checks before extensions are published.

“Up to now, the Open VSX Registry has relied primarily on post-publication response and investigation,” the foundation’s Director of Software Development, Christopher Guindon, said. “While this approach remains relevant and necessary, it does not scale as publication volume increases and threat models evolve.”

Registry Growth Forces New Security Controls#

Open VSX occupies a distinct role in the editor ecosystem. It is an open source project, while the Open VSX Registry is the hosted service operated by the Eclipse Foundation. The registry serves as shared infrastructure for VS Code compatible editors that cannot rely on Microsoft’s marketplace.

Open VSX has grown rapidly since becoming broadly available in 2021. By mid-2023, it hosted nearly 3,000 extensions from more than 1,500 publishers and had delivered over 40 million extension downloads, with usage continuing to climb. That scale prompted the Eclipse Foundation to form a dedicated Open VSX Working Group in 2023, acknowledging how far the registry had moved beyond its early, lighter-weight operating model.

As open source registries grow, they tend to follow a familiar arc. Early openness lowers friction and encourages adoption. Over time, they increasingly attract abuse from threat actors looking to exploit trust, scale, and automated distribution.

Open VSX is reaching that stage, as Guindon’s recent security update acknowledges that the registry is now "core infrastructure in the developer supply chain."

According to the Eclipse Foundation, developer tooling ecosystems have become a consistent target for abuse. Guindon listed common issues the registry sees repeatedly, including namespace impersonation, accidentally published secrets, misleading extensions, and supply chain attacks that spread quietly over time.

“Relying only on after-the-fact detection leaves a growing window of exposure,” he said. “Pre-publish checks help narrow that window by catching the most obvious issues earlier.”

That assessment comes after a series of Open VSX security incidents over the past year. Since late 2025, multiple waves of malicious extensions have been discovered on the registry, including GlassWorm-linked campaigns that abused extension trust and release paths. In several cases, malicious code remained available until users or researchers reported it.

Socket’s own threat research has documented both opportunistic malicious uploads and more recently targeted attacks involving compromised publisher accounts. While not all of these attacks are preventable through automated checks, they have increased pressure to reduce exposure earlier in the publication process.

Open VSX Will Begin Pre-Publish Monitoring in February#

To address this, Open VSX is introducing a new verification framework, developed in collaboration with security consultants from Yeeth Security. Guindon emphasized that while external expertise is involved, governance and long-term stewardship remain with the Open VSX project and the Eclipse Foundation.

“Most of this work is happening in the open,” he said, adding that a small set of security-sensitive details will remain private to reduce the risk of abuse or circumvention.

Over time, the framework is intended to support several classes of checks:

• Namespace impersonation designed to mislead users
• Secrets or credentials accidentally committed and published
• Malicious or misleading extensions
• Supply-chain attacks that spread quietly over time

The work is being tracked publicly in the Open VSX repository.

Rather than immediately blocking extensions, Open VSX plans a staged deployment.

According to Guindon, monitoring of newly published extensions will begin in February without blocking publication. This period will be used to tune detection, reduce false positives, and improve feedback. Enforcement is planned for March once the system behaves predictably and fairly.

“This staged rollout gives us room to get it right before it impacts publication flows,” he said.

Publishers may begin seeing new warnings or messages when issues are detected. Open VSX described these as “helpful nudges” rather than roadblocks for good-faith maintainers.

The planned checks are primarily aimed at reducing exposure to common, repeatable failure modes by intervening earlier in the publication process, before extensions reach users. They do not solve every class of supply chain risk.

Pre-publish scanning cannot reliably detect compromised publisher accounts or malicious updates that arrive through trusted release paths. Recent Open VSX incidents involving stolen publishing tokens fall into that category, where the extension, namespace, and author all appear legitimate.

“Pre-publish checks reduce the likelihood that obviously malicious or unsafe extensions make it into the ecosystem,” Guindon said, “which increases confidence in the Open VSX Registry as shared infrastructure.”

The Eclipse Foundation credited Alpha-Omega for supporting the work and noted that it is expanding the Open VSX team, including roles focused on security and platform engineering, as the changes roll out over the coming months.