Open VSX EUVD-2026-84343

Exploitation requires the specific misconfigured open-vsx.org edge/CDN deployment that reflected the requesting Origin header while also emitting Access-Control-Allow-Credentials: true on the authenticated /user/ endpoints - this is NOT reproducible in any self-hosted Open VSX install, since the software only sets allowCredentials(true) against a single exact origin derived from ovsx.webui.url and defines no origin-reflection behavior. The limiting factors are: (1) the victim must be actively logged in to open-vsx.org with a valid session cookie, and (2) the victim must visit an attacker-controlled web page (UI:P/UI:R) while that session is active; no attacker authentication is needed. Because the fix is operational at the hosted edge layer, exposure is bounded to the window before Eclipse corrected the CDN headers rather than to any installable version range.

This is a genuine high-priority issue where the CVSS 4.0 score of 8.7 is well-justified by the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H - network-reachable, low attack complexity, no attacker authentication required (the victim's own logged-in session is abused), and only passive user interaction (visiting a malicious page). All three impact metrics are High because the CORS-with-credentials misconfiguration lets any origin read authenticated /user/ responses AND, by reading the same-origin-protected /user/csrf token, defeat CSRF protection to forge write requests that mint a personal access token with publish and delete rights over the victim's namespaces. Signals do not conflict: the description's technical detail matches the vector precisely (PR:N is correct - the attacker needs no credentials because it rides the victim's cookies; UI:P/UI:R is correct because the victim must visit an attacker-controlled page). No EPSS score, KEV listing, or POC is provided, so there is no evidence of active exploitation - the risk is driven by the low bar to weaponize a well-understood, deterministic web flaw rather than by observed in-the-wild activity. One nuance worth verifying: the flaw was in the CDN/edge configuration of the single open-vsx.org deployment, not in the Open VSX application software itself, so remediation is operational (edge header configuration) and likely already applied server-side rather than distributed as a code patch.

An attacker lures a logged-in Open VSX user to a malicious web page, which uses the victim's browser to issue credentialed cross-origin requests to open-vsx.org; because the edge reflects the Origin with Access-Control-Allow-Credentials: true, the page reads /user, /user/tokens, and the /user/csrf token. It then chains the leaked CSRF token to POST /user/token/create and exfiltrates a personal access token carrying publish and delete rights over the victim's namespaces. No public exploit or POC is identified at time of analysis, but the technique is a deterministic, low-complexity CORS-plus-CSRF chain requiring only that the victim visit a page while authenticated.