For the last several years, the Eclipse Foundation Security Team has worked alongside our project communities to keep the software they produce trustworthy. We facilitate communication between security researchers and maintainers, help evaluate and assess the severity of reported issues, support coordinated disclosure, and advise on fixes and workarounds. As a CVE Numbering Authority for over ten years, we also assign CVE IDs and curate CVE records so the broader ecosystem can rely on accurate, complete vulnerability data.

For years, maintainers have asked security reporters for a fairly reasonable thing: reproduction steps. Not a vibe. Not a screenshot from a scanner. Not a majestic wall of speculative prose explaining how “an attacker could maybe possibly exploit this under unspecified conditions.” Just the steps. What did you do? What happened? What should have happened instead? Can I reproduce it before I spend my Saturday afternoon spelunking through a dependency graph held together by hope and YAML?

Trust is a core part of open source collaboration. At the Eclipse Foundation, we have always required committers to provide their real first and last name when signing their committer agreements, and we have long stated that certain committer information, including name and email address, is publicly displayed in connection with contributions. On June 2, the Eclipse Foundation will make optional identity verification generally available for Eclipse Foundation committers.

This is Part 2 of our response to the Trivy supply-chain compromise. Part 1 covered how to consume GitHub Actions safely. This post covers the other side: how to publish safely, so your project doesn’t become the upstream incident that impacts everyone downstream.

On March 19, 2026, an attacker used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 version tags in aquasecurity/trivy-action, and replace all 7 tags in aquasecurity/setup-trivy with malicious commits. On March 22, Aqua reported malicious Docker Hub images for versions 0.69.5 and 0.69.6. The malicious payload ran before the legitimate scanning logic and then let the workflow proceed normally. Every affected workflow looked fine. None of them were.

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.

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

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.

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.

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.