Electron’s protocol.registerFileProtocol and protocol.registerHttpProtocol may serve responses that are script‑readable across origins when the custom scheme’s supportFetchAPI flag is enabled while corsEnabled is disabled. This configuration allows a maliciously crafted response to disclose data to any script running on a different origin, leading to a confidentiality breach but not to code execution or denial of service.

The vulnerability affects applications built with the Electron framework when a custom scheme is registered with supportFetchAPI enabled and corsEnabled disabled. Prior to Electron releases 41.10.6, 42.9.2, 43.4.1, and 44.0.0‑beta.5 developers discovered that any untrusted content served through such schemes can be read by scripts from other origins. Schemes that are intentionally registered with corsEnabled enabled remain cross‑origin readable by design and are therefore not affected.

The CVSS score of 7.4 indicates a moderate‑to‑high severity weakness. The EPSS score is currently unavailable, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector is local or via an application that loads untrusted content; an attacker would need to supply or control that content. Consequently, the risk to systems depends on whether the application exposes such a scheme and loads external resources. In environments where the custom protocol is used exclusively with trusted content, the practical exploitability is low, but any exposure to untrusted data increases the likelihood of data leakage.