Eclipse Open Vsx
Monthly
Stored cross-site scripting in Eclipse Open VSX Registry (versions 0.1.0 through before 1.0.2) allows an attacker who self-registers a publisher account to upload a VSIX containing malicious HTML that the /vscode/unpkg/ endpoint serves inline as text/html within the open-vsx.org origin, with no Content-Security-Policy or Content-Disposition: attachment header. When a logged-in victim is lured to the resulting URL, the script runs in the registry's origin and can steal session tokens, mint Personal Access Tokens, and publish trojanized extension versions - turning a single XSS into a supply-chain compromise of VS Code, VSCodium, Cursor, and Windsurf users. No public exploit is identified at time of analysis and EPSS risk is low (0.17%), but the downstream blast radius is severe.
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.
Stored cross-site scripting in Eclipse Open VSX Registry (versions 0.1.0 through before 1.0.2) allows an attacker who self-registers a publisher account to upload a VSIX containing malicious HTML that the /vscode/unpkg/ endpoint serves inline as text/html within the open-vsx.org origin, with no Content-Security-Policy or Content-Disposition: attachment header. When a logged-in victim is lured to the resulting URL, the script runs in the registry's origin and can steal session tokens, mint Personal Access Tokens, and publish trojanized extension versions - turning a single XSS into a supply-chain compromise of VS Code, VSCodium, Cursor, and Windsurf users. No public exploit is identified at time of analysis and EPSS risk is low (0.17%), but the downstream blast radius is severe.
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.