open-vsx.org: Permissive Cross-domain Security Policy with Untrusted Domains
CVE-2026-90882 is a high-severity permissive cross-domain security policy with untrusted domains vulnerability in open-vsx.org from Eclipse Foundation, with a CVSS 4.0 base score of 8.7 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, but only if a user takes part, for example by opening a link or file. Affected open-vsx.org versions: 29/04/2026 through 07/09/2026. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.44% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Check which version of open-vsx.org you run against the affected versions below, and install the vendor's latest release.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
- Because the attack needs a user to take part, warn users about unexpected links and files related to this product until it is patched.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Eclipse Foundation | open-vsx.org | 29/04/2026 through 07/09/2026 | Not stated |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Attack requirements
- NoneThe attack does not depend on a particular deployment or configuration.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- PassiveA user only needs to do something routine, such as viewing a page.
- Confidentiality (vulnerable system)
- HighSerious loss of confidentiality on the vulnerable system.
- Integrity (vulnerable system)
- HighSerious loss of integrity on the vulnerable system.
- Availability (vulnerable system)
- HighSerious loss of availability on the vulnerable system.
- Confidentiality (other systems)
- NoneNo loss of confidentiality on systems beyond the vulnerable one.
- Integrity (other systems)
- NoneNo loss of integrity on systems beyond the vulnerable one.
- Availability (other systems)
- NoneNo loss of availability on systems beyond the vulnerable one.
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. Scored by CNA (eclipse.org).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Permissive Cross-domain Security Policy with Untrusted Domains
The product uses a web-client protection mechanism such as a Content Security Policy (CSP) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate.
How developers prevent this class of flaw
- Define a restrictive Content Security Policy or cross-domain policy file.
- Avoid using wildcards in the CSP / cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server.
- For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server.
More Permissive Cross-domain Security Policy with Untrusted Domains vulnerabilities (CWE-942)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
References
Other references
Recent Permissive Cross-domain Security Policy with Untrusted Domains vulnerabilities
- 8.1 High severity
- 8.1 High severity
- 8.2 High severity
- 9.3 Critical severity
- 7.4 High severity
- 9.8 Critical severity
Spotted an error? Tell us.