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.
The standard publishing process was not impacted. Recommendations have been issued to reduce future risk.
The Issue
On May 4, 2025, the Eclipse Foundation Security Team received a notification from Koi Security researchers about a potential vulnerability in the Eclipse Open VSX Registry extension publication process. The Security Team promptly contacted the Open VSX team, which confirmed the issue and began working on a fix. A first version of the fix was proposed within two weeks.
The Eclipse Open VSX Registry allows developers to publish extensions via CI/CD systems. To increase the availability of widely used extensions to its growing user base, it also includes a mechanism that automatically pulls, builds, and publishes a curated list of extensions. This list is publicly maintained in a configuration file. The vulnerability was found in this automated process.
Specifically, build scripts were executed without proper isolation, which could have inadvertently exposed a privileged token. This token allowed publishing of new extension versions under any namespace, including those not owned by an attacker. However, it did not allow deletion of existing extensions, overwriting of published versions, or access to administrative features of the registry.
To exploit this vulnerability, an attacker would need to either:
- Take over an already accepted extension (e.g., by compromising the developer’s account) and inject malicious code to exfiltrate the token; or
- Submit a new extension for inclusion in the auto-publish list, have it accepted (following a manual review of the pull request), and later push a new version with code designed to exfiltrate the token.
In both scenarios, any extension published using the token would appear to originate from the privileged user, which serves as a basis for the ongoing investigation into potential exploitation.
The Fix
The Eclipse Open VSX team implemented sandboxing for the extension build process to isolate builds and protect credentials. The fix underwent several iterations and was successfully deployed on June 24, 2025.
Importantly, this vulnerability only affected the auto-publishing mechanism. An attacker would have needed to control an extension listed for automatic updates or get their own extension added to the list. The standard extension publishing workflow is not affected by this vulnerability.
Timeline Summary
- May 4, 2025 – Vulnerability reported by Koi Security researchers
- May 5–17, 2025 – Issue confirmed and first version of fix developed
- May 17–June 24, 2025 – Development and testing of updated versions of the fix
- June 24, 2025 – Final fix approved and deployed; privileged token rotated
- Post-deployment – Audit of all affected extensions completed
- June 27, 2025 – CVE-2025-6705 published
- July 2, 2025 – Security advisory published
Investigation Summary
As the root cause was the lack of build isolation, the implemented patch introduces sandboxing and separation between build processes. It was deployed on June 24, 2025, and the potentially exposed privileged token was rotated following the deployment.
To determine whether the vulnerability had been exploited, the Eclipse Security and Open VSX teams audited all extensions published using the privileged token. These were cross-referenced with all extensions listed for automatic publication, whether currently or previously included. The focus was first on extensions that were published using the privileged token but were never added to the auto-publish list.
Findings: 14 extensions, encompassing a total of 20 unique published versions, were identified as having been published by the privileged user without a clear link to the auto-publish list. Although this is atypical, there has long existed a one-off workflow allowing Open VSX Registry operators to publish new extensions manually. It is most likely that these 20 revisions were published using this workflow.
As automation had reached its limits, the team manually reviewed the suspicious extensions. All were deemed legitimate and did not display signs of compromise. Indicators of compromise considered included:
- Mismatches between publication dates and repository tags/releases
- Publication of unknown versions
- Discrepancies between Eclipse Open VSX and the Microsoft Visual Studio Code Marketplace
- Sudden change in publishing behavior (e.g., from the extension owner to the privileged user)
- Other anomalous patterns
We then examined extensions legitimately published by the privileged user (by virtue of being listed for auto-publishing), searching for irregularities based on the indicators mentioned above. We identified 51 such extensions (61 unique extension versions), warranting further manual investigation. In all cases, however, the anomalies were ultimately ruled out. For example, while certain extension versions lacked a corresponding tag or formal release in their source repository, their version numbers had previously appeared in the build configuration history within the source repository. These versions were never officially released, but their publication dates aligned with the commit dates, strengthening the confidence that these were false positives rather than signs of compromise.
Conclusion: None of the 65 identified extensions (81 distinct published versions) showed evidence of being compromised. Nevertheless, as a precaution, all 81 versions have been deactivated while we contact their respective authors. Should evidence of compromise emerge, further advisories will be issued.
Recommendations
Based on our findings, we recommend the following actions to address the root causes of this vulnerability:
For Open VSX Registry operators:
- Mitigate risk from untrusted code: enforce a documented vetting process for new extensions before adding them to the auto-publish list. This limits exposure from potentially malicious submissions.
- Reduce exposure window: periodically review accepted extensions, especially after updates, to detect suspicious behavior that may emerge post-approval.
- Contain credential blast radius: replace shared, privileged tokens with namespace-specific credentials. This enforces the principle of least privilege and prevents cross-namespace publishing.
- Eliminate insecure workflows: consider disabling the auto-publishing mechanism entirely, or at a minimum, remove the one-off manual publishing feature, which bypasses the protections applied to the automated pipeline.
For the Open VSX user community:
- Exercise caution when installing or updating extensions. Extensions can access your development environment and may introduce risk if compromised. They are a critical part of the software supply chain and must be treated as such.
More Information
The Eclipse Open VSX Registry has grown significantly in popularity. We are grateful to Koi Security researchers for their responsible disclosure and encourage all users and vendors relying on Eclipse Open VSX to contribute to its continued security and sustainability. The Eclipse Foundation remains committed to ensuring the Open VSX Registry is a safe, trusted, and reliable platform for distributing and consuming secure, high-quality extensions.
For technical or security-related inquiries, please contact the Eclipse Foundation Security Team at security@eclipse-foundation.org.
