Between 12 and 14 September 2026, our GitLab instance was affected by CVE-2026-85706, a critical vulnerability in GitLab that allowed unauthenticated attackers to read files from the server. Some of those files contained sensitive credentials, and they were copied by attackers before we closed the hole. The vulnerability is now fully remediated, the exposure is contained, and our investigation is complete.

We owe the community a clear account of what happened, what we’ve done about it, and what (if anything) you need to do. This is that account.

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.