Security

In late March 2025, a security researcher in our community reported a security concern about a publicly accessible API endpoint containing user information on accounts.eclipse.org. After reviewing the issue, we determined this API endpoint was unnecessary and have since disabled it.

We looked through our access logs for the past few months and confirmed that the only requests were from the security researcher and the Eclipse Foundation staff who verified the report.

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.

It's time to reflect on the strides we've made in enhancing the security of our open source projects in 2024. 

In response to requests from various projects and after discussions between the Eclipse Foundation Security Team and the Architecture Council, we recently announced the creation of Project Security Teams.

The security track at OCX 2024 is packed with sessions that address the most pressing challenges and opportunities in open source security. Check this blog for a sneak peek at what the security track has in store.

The Eclipse Foundation is a CNA (CVE Numbering Authority), responsible for assigning vulnerability identification numbers, known as CVE (Common Vulnerability Enumerations), to our projects. This August, a new set of rules for CNAs comes into force.

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.

The Eclipse Foundation Security Team has been made aware of the vulnerability VU#421644 affecting multiple HTTP/2 implementations, that could cause an out-of-memory crash.