Open VSX Locks the Front Door: Eclipse Foundation Moves to Pre-Publish Security Checks for VS Code Extensions

Introduction

The Eclipse Foundation is preparing a major security shift for the Open VSX Registry, the open-source marketplace that distributes Visual Studio Code extensions beyond Microsoft’s own ecosystem. As developer tools become an increasingly attractive target for supply-chain attacks, the foundation is abandoning a purely reactive cleanup model and replacing it with proactive, pre-publication security controls. The goal is simple but critical: stop malicious or unsafe extensions before they ever reach developers’ machines.

the Original

The Eclipse Foundation, which oversees the Open VSX Registry, has announced that it will begin enforcing security checks before Visual Studio Code extensions are published. Until now, Open VSX relied largely on post-publication monitoring, removing extensions only after they were reported as harmful. According to Christopher Guindon, Director of Software Development at the Eclipse Foundation, this approach no longer scales as extension submissions increase and attacker techniques become more sophisticated.

Open-source registries and extension marketplaces have increasingly turned into high-value attack surfaces. Threat actors exploit trust in developer tools through techniques such as typosquatting, namespace impersonation, and account takeovers. A recent incident highlighted by Socket demonstrated how a compromised publisher account was used to distribute poisoned updates, underscoring how quickly damage can spread once a malicious extension is live.

To reduce this exposure window, Open VSX plans to introduce pre-publish verification checks. These checks aim to detect obvious impersonation attempts, accidentally committed secrets or credentials, and known malicious code patterns. Instead of publishing suspicious extensions immediately, the registry will quarantine them for manual review.

This move aligns Open VSX more closely with Microsoft’s Visual Studio Marketplace, which already uses multi-layered scanning. Microsoft scans extensions before publication, rescans them shortly after release, and periodically rechecks all existing packages in bulk.

The new Open VSX verification system will be rolled out in stages. During February 2026, the foundation will monitor new submissions without blocking them, allowing maintainers to tune detection logic, reduce false positives, and improve feedback mechanisms. Full enforcement is scheduled to begin the following month. According to Guindon, the objective is to raise the ecosystem’s baseline security, protect developers, and maintain a fair and predictable experience for legitimate publishers.

What Undercode Say:

The Eclipse Foundation’s decision is less about innovation and more about catching up with a harsh reality: developer tooling is now frontline infrastructure. VS Code extensions run with deep access to local systems, source code, credentials, and cloud environments. Treating extension registries as passive file hosts is no longer defensible in 2026.

What stands out is not that Open VSX is adding security checks, but how late this shift arrives. The registry has long positioned itself as an open alternative to Microsoft’s marketplace, yet openness without guardrails has become a liability. Attackers thrive in environments where publication is frictionless and trust is implicit. By moving checks earlier in the pipeline, Open VSX is finally acknowledging that speed must sometimes уступ security.

The staged rollout is a smart compromise. Immediate enforcement would risk alienating legitimate developers through false positives and opaque rejections. Using February 2026 as an observation period suggests the foundation understands that security tooling is only as good as its accuracy and transparency. Poorly tuned scanners can be just as damaging as no scanners at all.

However, pre-publish checks alone are not a silver bullet. Most recent extension-based attacks have relied on social engineering, compromised maintainer accounts, or subtle malicious logic that passes static analysis. Name impersonation and leaked secrets are the low-hanging fruit; advanced threats will still slip through. This makes continuous rescanning and behavioral monitoring just as important as front-door controls.

There is also an ecosystem question here. Open VSX serves downstream platforms like VSCodium and Gitpod, meaning a single malicious extension can propagate across multiple developer environments. By raising its security floor, Open VSX indirectly improves safety for the broader open-source tooling landscape, not just VS Code users.

The comparison with Microsoft’s marketplace is unavoidable. Microsoft’s multi-step scanning process has not eliminated malicious extensions, but it has significantly reduced blast radius and response times. Open VSX adopting similar practices signals a convergence toward shared security norms, even among ideologically different platforms.

Ultimately, this move reflects a broader trend: software supply chains are being professionalized under pressure. Registries that fail to adopt proactive defenses will increasingly be seen as unsafe by enterprises and serious developers. Open VSX’s changes are not about restricting freedom; they are about preserving trust in an ecosystem that attackers are actively trying to poison.

🔍 Fact Checker Results

✅ The Eclipse Foundation confirmed the shift from post-publication removal to pre-publish security checks.
✅ The rollout timeline includes a monitoring-only phase in February 2026 before enforcement.
❌ No evidence suggests the new system will fully prevent advanced or account-compromise-based attacks.

📊 Prediction

Open VSX’s pre-publish verification will significantly reduce low-effort attacks like typosquatting and credential leaks, but sophisticated malicious extensions will continue to emerge. Over time, pressure from enterprises and downstream platforms will likely push Open VSX toward even stricter review processes, narrowing the security gap with Microsoft’s marketplace while redefining what “open” means in high-risk developer ecosystems.