CVE-2026-13323: Open VSX Registry XSS Vulnerability

CVE-2026-13323 Overview

CVE-2026-13323 is a stored Cross-Site Scripting (XSS) vulnerability in the Open VSX Registry before version 1.0.2. The /vscode/unpkg/ endpoint serves user-supplied HTML files with Content-Type: text/html and omits both Content-Security-Policy and Content-Disposition: attachment response headers. An attacker registers a publisher account, uploads a VSIX package containing a crafted HTML payload, and lures an authenticated user to the resulting URL. The browser renders the payload inline within the open-vsx.org origin, allowing session token theft and Personal Access Token (PAT) generation. Because Open VSX distributes extensions to VS Code, VSCodium, Cursor, Windsurf, and compatible editors, a hijacked publisher account enables a supply chain attack against all downstream users.

Critical Impact
Attackers can hijack maintainer sessions, generate persistent PATs, and publish malicious extension updates that propagate to every editor consuming the Open VSX registry.

Affected Products

Eclipse Open VSX Registry versions prior to 1.0.2
Downstream editors consuming Open VSX extensions (VS Code, VSCodium, Cursor, Windsurf)
Self-hosted Open VSX Registry deployments before the patched release

Discovery Timeline

2026-07-01 - CVE-2026-13323 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-13323

Vulnerability Analysis

The flaw is a stored XSS issue [CWE-79] in the Open VSX Registry web service. The /vscode/unpkg/ endpoint retrieves files packaged inside a publisher-uploaded VSIX and returns them to the requesting browser. The endpoint sets Content-Type: text/html for HTML resources and does not attach a restrictive Content-Security-Policy header. It also omits Content-Disposition: attachment, which would force the browser to download rather than render the file. As a result, arbitrary HTML and JavaScript execute inside the open-vsx.org origin whenever an authenticated user opens the crafted URL.

Root Cause

Open VSX treats extension-embedded HTML as safe static content. The service serves those files with the origin's cookies in scope and without isolation. The absence of a strict Content-Security-Policy, a sandboxed origin, or an attachment disposition means publisher-controlled markup runs with the same trust as first-party registry code.

Attack Vector

An unauthenticated attacker first registers a publisher account through the standard signup flow. The attacker then packages a VSIX containing an HTML file with an embedded JavaScript payload and publishes it. The attacker delivers the resulting /vscode/unpkg/ URL to a target through phishing, social engineering, or a malicious link on a controlled site. When an authenticated Open VSX user visits the URL, the payload executes in the registry origin. The script can read session cookies scoped to the origin, invoke the PAT creation API to mint a long-lived token, and use that PAT to publish malicious versions of extensions the victim maintains. Downstream editors pulling automatic updates then install the trojanized extension.

See the Eclipse GitLab Vulnerability Report and the upstream fix in openvsx pull request 1922 for technical details.

Detection Methods for CVE-2026-13323

Indicators of Compromise

Requests to /vscode/unpkg/ paths returning Content-Type: text/html from a publisher namespace that is not an established, trusted maintainer.
Unexpected creation of Personal Access Tokens on maintainer accounts, particularly shortly after visits to Open VSX links delivered via chat or email.
Publication events for existing extensions originating from IP addresses or user-agents that do not match the maintainer's usual CI or workstation fingerprint.

Detection Strategies

Inspect web proxy and browser telemetry for outbound requests to open-vsx.org/vscode/unpkg/ followed by anomalous authenticated API calls to the same origin within the same session.
Alert on VSIX uploads containing .html files inside newly created publisher namespaces, and review those uploads for embedded <script> tags or event handlers.
Correlate maintainer account activity: token issuance, publisher metadata changes, and extension version publication should be reviewed together when they occur in rapid succession.

Monitoring Recommendations

Enable audit logging for PAT creation, extension publish, and namespace membership changes on self-hosted Open VSX deployments.
Monitor endpoints that consume Open VSX extensions for unexpected extension updates and behavioral changes in installed extensions immediately after an update.
Track referrers to /vscode/unpkg/ URLs to identify phishing infrastructure hosting the crafted links.

How to Mitigate CVE-2026-13323

Immediate Actions Required

Upgrade Open VSX Registry deployments to version 1.0.2 or later.
Rotate all Personal Access Tokens and force re-authentication of maintainer sessions after upgrade.
Audit recent extension version publications for unexpected changes and yank any suspicious releases.
Instruct maintainers to avoid clicking /vscode/unpkg/ links from untrusted publishers until patching is verified.

Patch Information

The fix is delivered in Open VSX Registry 1.0.2. The corrective change is tracked in openvsx pull request 1922, which adjusts response headers on the /vscode/unpkg/ endpoint so that user-supplied HTML no longer renders inline in the registry origin. Operators of open-vsx.org have deployed the fix upstream; self-hosted operators must apply the release manually.

Workarounds

Place a reverse proxy in front of the registry that rewrites responses from /vscode/unpkg/ to include Content-Disposition: attachment and a restrictive Content-Security-Policy: default-src 'none' header.
Block or rewrite Content-Type: text/html responses from the /vscode/unpkg/ path at the edge until the upgrade is complete.
Restrict publisher registration or require manual approval for new namespaces to reduce the anonymous attack surface.

bash

# Example nginx snippet to neutralize inline HTML rendering on /vscode/unpkg/
location /vscode/unpkg/ {
    proxy_pass http://openvsx_backend;
    proxy_hide_header Content-Disposition;
    add_header Content-Disposition "attachment" always;
    add_header Content-Security-Policy "default-src 'none'; sandbox" always;
    add_header X-Content-Type-Options "nosniff" always;
}