CVE-2026-13323: Open VSX HTML Injection & Session Hijacking Supply Chain Risk

Technical summary

The vulnerability stems from improper HTTP response headers on the /vscode/unpkg/ endpoint. User-supplied HTML files are served with Content-Type: text/html but lack both Content-Security-Policy (CSP) and Content-Disposition: attachment headers. Browsers therefore render the HTML inline within the open-vsx.org security context, permitting same-origin requests (including authenticated session cookies and tokens) to be exfiltrated by injected scripts. An attacker registers a publisher account, uploads a VSIX containing crafted HTML, and socializes the resulting URL. Upon visitation by an authenticated extension maintainer or moderator, malicious JavaScript executes with full access to the user's session and can programmatically interact with Open VSX APIs to create PATs, modify extension metadata, or push malicious versions. The supply chain risk is acute because extension distribution pipelines funnel updates to millions of editor instances.

Business impact

For Open VSX maintainers and the Eclipse Foundation, a successful attack undermines the integrity and trustworthiness of the entire extension ecosystem. For extension publishers, compromised accounts lead to loss of control over their intellectual property and user trust. For end users and organizations deploying VS Code variants, a poisoned extension update represents a persistent backdoor or data exfiltration vector embedded in development toolchains. Given that developers often run extensions with broad system permissions, a supply chain compromise can escalate to code execution on developer machines and CI/CD pipelines, with downstream impact on all software built by affected teams.

Affected systems

Open VSX Registry versions prior to 1.0.2 are affected. The vulnerability impacts all editor clients that consume Open VSX extensions, including VS Code, VSCodium, Cursor, Windsurf, and any third-party editor with Open VSX integration. Publishers and moderators with authenticated sessions on open-vsx.org are the primary targets, but end users installing affected extensions face downstream compromise risk.

Exploitability

Exploitation requires an attacker to register a free publisher account on Open VSX Registry—a low barrier to entry—and upload a VSIX containing an HTML payload. The attacker then must convince an authenticated Open VSX user (typically an extension maintainer or moderator) to click a link to the malicious HTML file. The attack does not require network-level access and relies on social engineering rather than complex exploitation. The CVSS score of 4.1 (MEDIUM) reflects the requirement for user interaction and the limited immediate scope to the affected user's own session, though the supply chain risk potential is strategically significant.

Remediation

Upgrade Open VSX Registry to version 1.0.2 or later, which applies proper HTTP security headers to the /vscode/unpkg/ endpoint. Specifically, the fix should include setting Content-Disposition: attachment for HTML files and implementing a restrictive Content-Security-Policy to prevent inline script execution. Additionally, Open VSX operators should review and tighten access controls on publisher accounts, implement rate-limiting on account creation, and consider multi-factor authentication for maintainers and moderators.

Patch guidance

Apply the update to Open VSX Registry 1.0.2 as soon as feasible. If you operate an Open VSX instance, refer to the official Eclipse Foundation release notes and deployment documentation to ensure the patch is correctly applied. If you are an extension publisher or maintainer, assume your session may have been exposed if you visited suspicious HTML links on open-vsx.org prior to the patch deployment; rotate your PATs and session tokens immediately. Monitor account activity logs for unauthorized access or extension version changes.

Detection guidance

Monitor HTTP access logs on the /vscode/unpkg/ endpoint for unusual HTML file requests, especially those followed by API calls to generate tokens or publish extensions from unexpected accounts. Search logs for Content-Disposition headers that are absent or improperly configured. Audit Open VSX accounts for creation of new PATs or changes to extension metadata in a short time window. On the client side, monitor VS Code and editor logs for unexpected extension update downloads or installations. Monitor network traffic for exfiltration of session-like strings from development machines to external hosts.

Why prioritize this

Although the CVSS score is MEDIUM (4.1), the attack pattern—combining low exploitation difficulty, user interaction, and supply chain risk—warrants prioritization for infrastructure operators and extension maintainers. A single compromised high-profile extension can poison millions of editor installations. Patch deployment should be expedited to close the window of opportunity for attackers to harvest maintainer credentials.

Risk score, explained

The CVSS 3.1 score of 4.1 reflects Attack Vector: Network, Attack Complexity: Low, Privileges Required: Low (attacker needs a free publisher account), User Interaction: Required, and Scope: Changed with impact limited to Integrity (unauthorized token generation and extension modification). The score does not fully capture the downstream supply chain and CI/CD risks posed by a compromised extension, which organizational risk models should factor in separately. Organizations with many developers relying on Open VSX extensions should consider this a higher priority within their environment.

Frequently asked questions