CVE-2025-6705
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-27

Last updated on: 2025-07-31

Assigner: Eclipse Foundation

Description
A vulnerability in the Eclipse Open VSX Registry’s automated publishing system could have allowed unauthorized uploads of extensions. Specifically, the system’s build scripts were executed without proper isolation, potentially exposing a privileged token. This token enabled the publishing of new extension versions under any namespace, including those not controlled by an attacker. However, it did not permit deletion of existing extensions, overwriting of published versions, or access to administrative features of the registry. The issue was reported on May 4, 2025, fully resolved by June 24, and followed by a comprehensive audit. No evidence of compromise was found, though 81 extensions were proactively deactivated as a precaution. The standard publishing process remained unaffected. Recommendations have been issued to mitigate similar risks in the future.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-27
Last Modified
2025-07-31
Generated
2026-05-07
AI Q&A
2025-06-27
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
eclipse open_vsx *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-653 The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
CWE-913 The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in open-vsx.org allowed attackers to run arbitrary build scripts for auto-published extensions due to missing sandboxing in the continuous integration (CI) job runs. An attacker with access to an existing extension could exploit this to take over the marketplace's service account. The issue was fixed by replacing the use of Node.js's child_process module with separate GitHub Actions jobs to sandbox the build process, isolating build tasks and preventing arbitrary script execution. [1]


How can this vulnerability impact me? :

If exploited, this vulnerability could allow an attacker to execute arbitrary build scripts within the marketplace's CI environment, potentially leading to takeover of the marketplace's service account. This could result in unauthorized control over extension publishing, compromise of the marketplace infrastructure, and distribution of malicious extensions to users. [1]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

Detection of this vulnerability involves identifying if the publish-extension process is running un-sandboxed build scripts via Node.js's child_process module. Since the vulnerability relates to the build process spawning child processes without sandboxing, you can check for usage of child_process in the publish-extension workflows or running processes. For example, on the system hosting the build, you might run commands like `ps aux | grep node` to look for suspicious child processes spawned by Node.js. Additionally, reviewing GitHub Actions workflows for the presence of child_process usage or lack of isolated jobs can help detect vulnerable setups. However, no specific detection commands are provided in the resources. [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include updating the publish-extension workflows to replace the use of Node.js's child_process module with separate, sandboxed GitHub Actions jobs for building extensions. This approach isolates build tasks and prevents arbitrary script execution. Implementing rate limiting on job triggers can help manage concurrency limits. Applying the fix merged on June 24, 2025, from the referenced pull request (#881) is recommended to secure the build process. Additionally, testing the workflows locally using the provided local-workflow.js script can help ensure the fix is correctly applied. [1]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart