Over the past few weeks, the Open VSX team and the Eclipse Foundation have been responding to reports of leaked tokens and related malicious activity involving certain extensions hosted on the Open VSX Registry. We want to share a clear summary of what happened, what actions we’ve taken, and what improvements we’re implementing to strengthen the security of the ecosystem.

Background

Earlier this month, our team was alerted to a report from Wiz identifying several extension publishing tokens inadvertently exposed by developers within public repositories. Some of these tokens were associated with Open VSX accounts.

This security advisory provides additional technical details following our initial statement and the corresponding CVE record.

TL;DR

A vulnerability in the Eclipse Open VSX Registry’s automated publishing system could have allowed unauthorized extension uploads. It did not affect existing extensions or admin functions.

The issue was reported on May 4, 2025, fully fixed by June 24, and followed by a complete audit. No evidence of compromise was found, but 81 extensions were proactively deactivated as a precaution.

On May 4th, the Eclipse Foundation (EF) Security Team received a notification from researchers at Koi Security regarding a potential issue in the Eclipse Open VSX marketplace extension publication process. The EF Security Team immediately contacted the Eclipse Open VSX team, and upon confirming the issue, work on a fix was promptly initiated.

Following several iterations and thorough testing (necessary due to the intrusive nature of the change to the extension build process) the fix was successfully deployed on June 24th.

We are pleased to announce that the Eclipse Foundation has been selected by the Sovereign Tech Agency for a new service agreement. Through this collaboration, the Sovereign Tech Fund—a program of the Sovereign Tech Agency—will invest in the development, improvement, and maintenance of open digital base technologies worldwide, driving significant security enhancements across Eclipse Foundation projects.

Why This Matters

Open source software is the backbone of countless industries and technologies. At the Eclipse Foundation, we host a diverse range of critical projects, including:

Recent reports indicate that cybercriminals are exploiting the Windows DLL side-loading technique using the legitimate jarsigner.exe executable to propagate malware. This binary is commonly included in Java distributions such as Eclipse Temurin, which is also bundled with the Eclipse Integrated Development Environment (IDE). This has understandably raised concerns about the role of our software and whether the Eclipse Foundation or its projects bear any responsibility.

As the Head of Security at the Eclipse Foundation, I want to clarify the situation, explain DLL side-loading, and reaffirm our commitment to security and collaboration with the community. My goal is to provide a clear understanding of both the technical aspects of this misuse and our approach to maintaining a secure ecosystem.

On November 20, 2024, the Board of Director of the Eclipse Foundation approved version 1.2 of its Security Policy. This update brings significant enhancements aimed at improving the management, resolution, and disclosure of vulnerabilities within the Eclipse community. Here’s a rundown of the key changes and what they mean for Eclipse projects and users.

In the fast-paced world of software development, open source has emerged as a catalyst for innovation. But with this rapid growth comes an equally crucial responsibility: security. As open source continues to reshape the digital landscape, ensuring robust security measures is no longer optional; it’s essential. That’s why Open Community Experience (OCX) is placing a strong emphasis on the latest advancements in open source security.

The Eclipse Foundation is pleased to announce the successful implementation of two-factor authentication (2FA) for all committers on both gitlab.eclipse.org and github.com. This initiative, aimed at bolstering the security of our source code repositories, mandates that all users with write access to an Eclipse Project repository (commonly known as committers) on GitHub and the Eclipse Foundation GitLab instance must use 2FA.

Two-factor authentication adds an extra layer of security by requiring not only a password but also a second form of verification. This significantly reduces the risk of unauthorized access and enhances the overall security of Eclipse Foundation projects.

A software provenance attestation is a signed document that associates metadata with an artifact, encompassing details like the artifact’s origin, build steps, and dependencies. This information is critical for verifying the artifact’s authenticity and integrity. Featuring a cryptographic signature, provenance attestation ensures the document remains unaltered, playing a vital role in mitigating supply chain attacks. By scrutinizing the provenance of binaries, users can thwart the execution of malicious code on their systems. Let’s delve into some concrete examples:

In the ever-evolving landscape of open-source software development, the creation and distribution of artifacts—such as compiled binaries, libraries, and documentation—represent the tangible results of a multifaceted process. These artifacts are more than just a collection of code; they are the final product of myriad decisions, alterations, and contributions, each with its unique narrative. It’s essential to grasp these narratives or the provenance of these artifacts, to secure the supply chain effectively. Moreover, the integrity and security of these artifacts are paramount, as they underpin the trust and reliability users expect. This post aims to demystify the concept of provenance for these released artifacts. We will delve into why a comprehensive understanding of their origins and the path they take—examined through the lens of the journalistic 5W1H (Who, What, When, Where, Why, and How)—is crucial for enhancing the security posture of an open source project’s supply chain.