CVE-2025-6705: Eclipse Open VSX Auth Bypass Vulnerability

CVE-2025-6705 Overview

CVE-2025-6705 is a high-severity vulnerability in the Eclipse Open VSX Registry's automated publishing system. The flaw stems from build scripts executing without proper isolation, which exposed a privileged publishing token. An attacker who obtained this token could publish new extension versions under any namespace, including namespaces they did not control.

The token did not permit deletion of existing extensions, overwriting of published versions, or access to administrative registry features. The Eclipse Foundation received the report on May 4, 2025, and completed remediation by June 24, 2025. A follow-up audit found no evidence of compromise, though 81 extensions were proactively deactivated as a precaution.

Critical Impact
An attacker who exfiltrated the exposed publishing token could push malicious extension versions to any Open VSX namespace, enabling supply-chain attacks against downstream IDE users.

Affected Products

Eclipse Open VSX Registry (open-vsx.org)
Eclipse Foundation publish-extensions automated publishing pipeline
Downstream editors consuming Open VSX (VSCodium, Gitpod, Eclipse Theia, Cursor and similar)

Discovery Timeline

May 4, 2025 - Vulnerability reported to the Eclipse Foundation
June 24, 2025 - Issue fully resolved and comprehensive audit initiated
2025-06-27 - CVE-2025-6705 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-6705

Vulnerability Analysis

The Open VSX Registry uses an automated pipeline in the EclipseFdn/publish-extensions repository to build and publish third-party VS Code extensions. The pipeline invoked untrusted build scripts belonging to individual extensions within the same execution context that held a highly privileged publishing token.

Because the build scripts were not sandboxed, any extension author whose script ran in the pipeline could read environment variables and file-system state accessible to the runner. This exposed the token used to sign and publish extensions across the entire registry. The weakness is categorized as CWE-653: Improper Isolation or Compartmentalization.

The registry's standard, manually authenticated publishing workflow was not affected. Only the automated republish path introduced the exposure.

Root Cause

The root cause is missing isolation between untrusted extension build logic and the privileged credential material used by the publisher. The pipeline treated third-party build steps as trusted code, granting them ambient access to the publishing token rather than issuing short-lived, per-namespace credentials or running builds in an unprivileged sandbox.

Attack Vector

An attacker would submit or modify an extension whose build script was consumed by the automated publishing pipeline. When the pipeline executed that script, it could exfiltrate the publishing token to an attacker-controlled endpoint. With the token, the attacker could then publish new extension versions under any namespace on the registry, creating a foothold for supply-chain compromise of IDE users who install or auto-update those extensions.

The vulnerability requires network access and low privileges (the ability to contribute an extension to the pipeline). No user interaction with the eventual victim is required at the token-theft stage. See the remediation pull request in the EclipseFdn/publish-extensions repository for the isolation changes.

Detection Methods for CVE-2025-6705

Indicators of Compromise

Unexpected new versions of Open VSX extensions published outside the maintainer's normal release cadence or from unfamiliar automation accounts.
Extensions on the list of 81 proactively deactivated packages published by the Eclipse Foundation during the June 2025 audit.
Outbound network connections from developer or CI hosts to domains associated with recently updated extensions immediately after installation.

Detection Strategies

Inventory installed Open VSX extensions across developer workstations and CI images, and cross-reference version metadata against the maintainer's official release channel.
Hunt for anomalous child processes spawned by editor host processes (code, codium, theia) following extension install or update events.
Monitor CI/CD build logs for scripts that read environment variables containing publishing tokens or write to unexpected network destinations.

Monitoring Recommendations

Enable file integrity monitoring on extension install directories such as ~/.vscode-oss/extensions and ~/.openvsx/extensions.
Alert on outbound connections from editor and language-server processes to newly registered or low-reputation domains.
Log and review all extension version pinning changes in shared developer environments and container base images.

How to Mitigate CVE-2025-6705

Immediate Actions Required

Update to the current Open VSX Registry release; the underlying pipeline defect was resolved on June 24, 2025.
Audit installed extensions against the Eclipse Foundation's list of 81 deactivated packages and remove any matches from developer and CI environments.
Rotate any secrets or credentials that were accessible to developer workstations during the exposure window preceding the fix.

Patch Information

The Eclipse Foundation resolved the isolation defect in the publish-extensions pipeline. The remediation details are tracked in GitHub Pull Request #881. No action is required on the client side for the pipeline fix itself, but consumers should verify that installed extensions are current and untainted.

Workarounds

Pin extensions to known-good versions in shared developer images until the audit posture of each extension is confirmed.
Restrict which Open VSX namespaces are permitted in enterprise editor deployments using allow-lists.
Require code review and provenance verification for any extension update pulled into CI base images.

bash

# Example: enumerate installed Open VSX extensions and their versions for audit
codium --list-extensions --show-versions > installed-extensions.txt

# Example: pin an extension to a reviewed version in a devcontainer
# .devcontainer/devcontainer.json
#   "customizations": {
#     "vscode": {
#       "extensions": [
#         "publisher.extension-name@1.2.3"
#       ]
#     }
#   }