CVE-2026-90882: Reflected arbitrary origins with credentials, allowing cross-origin reads of authenticated user data
The open-vsx.org deployment returned Access-Control-Allow-Origin reflecting the requesting origin together with Access-Control-Allow-Credentials: true on the authenticated /user/ endpoints. A page on any origin could therefore issue credentialed requests to the service in a logged-in user's browser and read the responses.
This exposed /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name} and /user/namespace/{name}/members, and — because /user/csrf was readable the same way — allowed the CSRF protection on write endpoints to be defeated. Chaining the two, an attacker page could call /user/token/create and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces.
The headers were emitted by the CDN/edge layer, not by the application: the Open VSX software sets allowCredentials(true) in exactly one place, against a single exact origin derived from ovsx.webui.url, and defines no CORS mapping on /user/ beyond it. No configuration of the software produces origin reflection with credentials.
Affected Software
Event History
Frequently Asked Questions
Which users and data were exposed to a malicious website?
Any logged-in user whose browser visited an attacker-controlled origin could have authenticated responses read cross-origin. Exposed endpoints included account details, tokens metadata, namespaces, extensions, search results, and namespace membership; an attacker could also create and exfiltrate a personal access token with publish and delete rights over the victim's namespaces.
Did a standard Open VSX software configuration cause this behavior?
No. The vulnerable origin reflection with credentials was emitted by the CDN or edge layer, not by the Open VSX application. The software permits credentials for only one exact origin derived from ovsx.webui.url and does not define a broader /user/ CORS mapping.
What attacker interaction was required?
The attacker needed a logged-in victim to load an attacker-controlled page. That page could make credentialed browser requests to the affected /user/ endpoints and read the responses because the service reflected the attacker's origin while allowing credentials.
Why could this lead to modification of a victim's account resources rather than only data disclosure?
The readable /user/csrf endpoint exposed the CSRF token needed by write endpoints. An attacker could use it to call /user/token/create, then read the resulting personal access token and use its publish and delete permissions.