Search
Search Results (5 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-12999 | 1 Eclipse | 1 Open Vsx | 2026-09-21 | N/A |
| UrlUtil.getBaseUrl builds the absolute URLs in a response — download links, icons, asset and API URLs — from the X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix request headers, with no check on whether the sender was a trusted proxy, falling back to the client-supplied Host header. Those responses are cached under keys that do not include the host (extension.json since 0.6.0, namespace.details.json since 0.9.0, sitemap since 0.14.5, latest.extension.version.vscode since 0.34.2). A single request carrying a forged header therefore places attacker-chosen URLs into an entry served to every other client for the lifetime of that entry — one hour by default, and cluster-wide where ovsx.redis.enabled is set. The VSIX download URL, its signature URL and the public key URL are all derived from the same base URL, so extension signing does not limit the impact: an attacker who poisons an entry supplies the package, the signature over it, and the key used to verify it. Exploitability depends on deployment topology. A server reachable directly by clients, or fronted by a proxy that relays the client's X-Forwarded-Host rather than overwriting it, is exploitable by an unauthenticated remote attacker. A proxy that overwrites the header is not. An unauthenticated attacker can poison Open VSX's per-extension metadata cache with attacker-controlled download, signature, and public-key URLs by supplying a crafted X-Forwarded-Host header, causing downstream VS Code-compatible editors to fetch and install a malicious VSIX. Workarounds (unpatched versions) 1. Configure the reverse proxy to set rather than relay X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix — note that nginx's $host is the client's Host header and is not a safe value. 2. Ensure the server is not reachable except through that proxy. 3. Flush the caches afterwards; poisoned entries survive the configuration change. | ||||
| CVE-2026-13323 | 1 Eclipse | 1 Open Vsx | 2026-07-02 | 4.1 Medium |
| In Open VSX Registry before 1.0.2, the /vscode/unpkg/ endpoint serves user-supplied HTML files with Content-Type: text/html and without a Content-Security-Policy or Content-Disposition: attachment response header. An unauthenticated attacker can register a publisher account, upload a VSIX containing a crafted HTML payload, and induce an authenticated user to visit the resulting URL. The browser renders the file inline in the open-vsx.org origin context, enabling session token exfiltration, persistent Personal Access Token (PAT) generation, and unauthorized publication of malicious extension versions. Because Open VSX extensions are distributed to VS Code, VSCodium, Cursor, Windsurf, and compatible editors, a compromised extension update constitutes a supply chain attack against all downstream users. | ||||
| CVE-2026-4983 | 1 Eclipse | 1 Open Vsx | 2026-06-23 | 4.1 Medium |
| Open VSX Registry does not sanitize SVG files uploaded as extension icons prior to storage, and serves them with Content-Type: image/svg+xml without security headers such as Content-Security-Policy or Content-Disposition: attachment. This allows an attacker to publish an extension with a malicious SVG icon and achieve stored cross-site scripting (XSS) when a user navigates directly to the icon URL. On deployments using local storage, script execution occurs within the Open VSX application origin, enabling session hijacking, authentication token theft, and unauthorized extension publishing. On deployments backed by external storage (such as open-vsx.org with an S3-backed CDN), execution is confined to the storage origin, reducing impact but still permitting phishing attacks and credential harvesting through attacker-crafted pages. | ||||
| CVE-2025-6705 | 1 Eclipse | 1 Open Vsx | 2025-07-31 | 5.3 Medium |
| 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. | ||||
| CVE-2025-1007 | 1 Eclipse | 1 Open Vsx | 2025-07-31 | 5.3 Medium |
| In OpenVSX version v0.9.0 to v0.20.0, the /user/namespace/{namespace}/details API allows a user to edit all namespace details, even if the user is not a namespace Owner or Contributor. The details include: name, description, website, support link and social media links. The same issues existed in /user/namespace/{namespace}/details/logo and allowed a user to change the logo. | ||||
Page 1 of 1.