Open VSX takes a decisive step by implementing pre-publication verifications to stop malicious extensions

The Eclipse Foundation has decided to take a significant step to tighten the security of its Open VSX extension repository, the alternative record where accessories compatible with Visual Studio Code are published. So far the dynamics had been essentially reactive: when a malicious extension was detected it was investigated and withdrawn. It is now considered to check the packages before they become publicly available, with the aim of reducing the exposure window and stopping the spread of harmful code in the supply chain.

The idea behind these pre-publication checks is simple but powerful: intercept clear signs of problems - from name supplanting attempts to accidentally included secrets - before an extension reaches millions of developers. According to the Eclipse Foundation team, this strategy aims to raise the minimum level of registration security and provide greater confidence in Open VSX as a shared infrastructure. You can read the official release and technical details on the blog of the Eclipse Foundation Here..

Change does not come in the vacuum. Package repositories and markets have become low cost and high impact targets for malicious actors: it is enough to introduce an infected extension or package or to pose as a legitimate author to reach thousands or millions of users. Previous large-scale incidents, such as the compromising campaign against SolarWinds that affected the software supply chain, made it clear that the implicit confidence in components and distributions can be exploited with serious consequences; on this case there is an analysis and public notice by the authorities. Here..

Another useful reference to understanding the overall context of supply chain threats is the work of the security community: projects such as the OWASP on software supply chain security They collect attack patterns and good practices to mitigate them. In the case of extension records, the most recurrent vectors include name supplanting (namespace impersonation), error publication of credentials within the code, and identifiable behavior patterns associated with malicious packages.

To avoid blocking developers in good faith by mistake, the Eclipse Foundation has decided to deploy the new verification gradually. During February 2026 the system will operate in observation mode: the newly uploaded publications will be monitored without preventing their immediate availability, which will make it possible to refine rules, reduce false positive and improve the messages that are returned to the authors. The intention is to start the effective implementation phase the following month, thus giving a period of both technical and community adaptation.

This phased approach is important because automatic checks can catch many obvious problems, but they can also generate friction if they are not well calibrated. Code secret detectors, name or heuristic comparison systems that point to suspicious patterns must be combined with clear human processes and appeal pathways so that legitimate developers do not suffer unnecessary interruptions.

It's not an exclusive Open VSX experiment. Microsoft already applies a validation process in its own extension market, with initial scans, rescans shortly after publication and regular audits to the entire package corpus, as described by the company in its documentation on safety and confidence of the Market Here.. Learning from existing practices and adapting measures that work in other ecosystems helps not to repeat errors and consolidate more standard responses to common threats.

What can the developer community that publishes on Open VSX expect? In practice, where the system identifies a rise with problematic signals, the extension may be left in a review tail or in temporary quarantine until additional controls are passed. Motifs can range from obvious coincidences with popular extension names - suggesting a possible supplanting - to the presence of keys or tokens in the package, or patterns that detection tools consider malicious. For good faith authors this will add one more step to the publication flow, but the stated intention is for the process to be predictable and fair, offering useful feedback to correct and retry the publication.

The news also opens a broader discussion on how to balance security, ease of publication and transparency. Increasing verification reduces risks, but requires resources, maintenance and clear governance to avoid bias in detections. In addition, the privacy of the information contained in the packages to be analysed and the protection of authors' rights are aspects that must be taken care of in operational implementation.

In short, the Eclipse Foundation's commitment is to move from a reactive to a proactive position by applying automated controls prior to publication and combining them with human reviews where necessary. If it is run with a sensitivity to the developers and with transparency on criteria and appeal pathways, it can raise confidence in Open VSX and reduce the risk of malicious extensions reaching users' machines. For those who want to consult the register itself and its operation, the official Open VSX site is available Here..