Electron EUVD-2026-89093

Exploitable only when an Electron application (1) registers a custom scheme via protocol.registerFileProtocol or protocol.registerHttpProtocol with supportFetchAPI enabled AND corsEnabled disabled, and (2) loads untrusted content within the same session that can issue cross-origin requests to that scheme. Limiting factors: UI:R requires the victim to load the malicious/untrusted content; the app must expose exactly this scheme configuration; schemes deliberately registered with corsEnabled=on are readable by design and NOT vulnerable; and the app must actually serve sensitive data through the affected file/http protocol handlers. Apps that never register such a scheme, or never load untrusted content in that session, are unaffected.

This is a real but conditionally-gated web-security flaw, not a raw-network RCE. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N = 7.4) reflects a same-origin-policy bypass: responses served by protocol.registerFileProtocol/registerHttpProtocol for a custom scheme registered with supportFetchAPI enabled but corsEnabled disabled remained script-readable across origins, letting untrusted content in the same session read another origin's response bodies (C:H, S:C scope change, no integrity/availability impact). No EPSS score, no CISA KEV entry, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' The commit evidence (OpaqueResponseFilter forcing FetchResponseType::kOpaque on no-cors cross-origin loads) confirms the root cause and that this is a residual completion of the earlier CVE-2026-70604 fix - meaning the class of bug was already known and partially patched, raising the plausibility that someone could reconstruct it from the diff even though no POC is cited. Real-world priority is tempered by the narrow precondition: only apps that both register such a scheme (supportFetchAPI on / corsEnabled off) AND load untrusted content in the same session are affected; schemes intentionally set corsEnabled=on are cross-origin readable by design and are out of scope. So despite the 'ubiquitous framework' footprint, the exploitable population is a subset of Electron apps, making this a medium operational priority rather than a drop-everything event.

An Electron app registers a custom scheme via registerFileProtocol/registerHttpProtocol with supportFetchAPI enabled but corsEnabled disabled, and also loads untrusted or attacker-influenced web content in the same session. The attacker's content issues a cross-origin fetch/XHR to that custom scheme and reads the response body (e.g., local files or privileged HTTP responses) that should have been opaque, exfiltrating it. No public POC is cited, but the fix commit diff is available and could aid reconstruction; UI:R means a victim must load the malicious content.