Description

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme registered with supportFetchAPI enabled but corsEnabled disabled could remain script-readable across origins. This residual issue completes the remediation for CVE-2026-70604. Applications are affected only when they expose such a scheme and load untrusted content in the same session. Schemes intentionally registered with corsEnabled enabled remain cross-origin readable by design. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-29T17:17:07.813Z",
  "pubdate": "2026-09-29T17:17:07.813Z",
  "executiveSummary": "Electron is susceptible to a cross-origin data leakage vulnerability originating from improper enforcement of Same-Origin Policy (SOP) controls on custom schemes. The vulnerability resides in the interaction between 'protocol.registerFileProtocol' and 'protocol.registerHttpProtocol' when 'supportFetchAPI' is enabled but 'corsEnabled' is explicitly disabled.\nThe flaw allows unauthorized script access to cross-origin resources that should otherwise be restricted. An attacker capable of executing arbitrary JavaScript within a renderer process can potentially bypass origin isolation to read sensitive data served through the affected custom schemes.\nThis issue is considered a remediation update for CVE-2026-70604. Risk implications include the potential exfiltration of sensitive information, such as authentication tokens or proprietary data, if the application processes untrusted content in the same session as the vulnerable protocol. The vulnerability is effectively mitigated by updating to the patched versions provided by the vendor.",
  "technicalDetails": "The vulnerability is localized within the Electron protocol registration logic, specifically concerning how custom schemes manage cross-origin request headers and policy enforcement. When an application registers a custom scheme using 'protocol.registerFileProtocol' or 'protocol.registerHttpProtocol' with 'supportFetchAPI' set to true, the browser engine attempts to integrate the scheme into the fetch ecosystem. If 'corsEnabled' is set to false, the system fails to properly enforce mandatory SOP checks on the responses returned by these schemes.\nThe root cause is a deficiency in the internal response object propagation, which allows responses retrieved via these protocols to remain readable by scripts residing on different origins. In a standard secure environment, the browser should block access to cross-origin responses that lack appropriate CORS headers or if the origin does not match the requester. Because the custom scheme remains script-readable despite the configuration, the 'corsEnabled: false' setting provides a false sense of security.\nThe attack flow requires the victim application to process untrusted or malicious content within the same renderer session. An attacker injects a script into the renderer, which then initiates a fetch request or an XMLHttpRequest to the custom scheme. Due to the failure in the underlying security boundary, the response is returned to the malicious script instead of being blocked by the browser's SOP mechanism. This allows the attacker to extract headers, response bodies, or metadata associated with the target custom scheme.\nThe vulnerability affects Electron versions prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5. There are no specific authentication or privilege requirements for exploitation beyond the capability to execute JavaScript within a vulnerable renderer process. Network exposure is confined to the local application runtime; however, the impact is severe if the application processes sensitive user data or interacts with local files through these custom protocols.\nPost-exploitation, the attacker can systematically scrape data from internal application sources, bypass intended origin restrictions, and potentially facilitate further attacks such as session hijacking or data exfiltration. The fix involves ensuring that the protocol handlers strictly enforce cross-origin constraints when 'supportFetchAPI' is active, regardless of the 'corsEnabled' status, unless explicitly permitted by design."
}