CVE-2026-102675 in Electron
Summary
by MITRE • 09/29/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
Electron serves as a foundational framework for developing cross-platform desktop applications by leveraging web technologies such as JavaScript, HTML, and CSS. A critical security flaw was identified in specific versions of this framework, namely those prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5. The vulnerability pertains specifically to the handling of custom URL schemes registered via protocol.registerFileProtocol or protocol.registerHttpProtocol when the configuration includes supportFetchAPI enabled but corsEnabled disabled. Under these specific conditions, responses served through these protocols remained script-readable across different origins, violating fundamental browser security boundaries designed to isolate content from distinct sources.
The technical core of this vulnerability lies in the improper enforcement of Cross-Origin Resource Sharing policies within Electron's internal networking stack when dealing with custom schemes. When corsEnabled is explicitly disabled for a registered scheme, the framework was inadvertently allowing JavaScript code originating from one origin to access resources loaded via that custom scheme from another origin. This behavior contradicts the expected isolation model where cross-origin requests should be blocked or restricted unless explicit permissions are granted through CORS headers and configuration settings. The issue represents a residual gap in the remediation efforts for CVE-2026-70604, indicating that previous fixes did not fully address all attack vectors related to custom scheme handling under specific API configurations.
The operational impact of this vulnerability is significant for applications that expose such custom schemes and simultaneously load untrusted content within the same session. An attacker who can influence or control one part of an Electron application could potentially exploit this cross-origin leakage to read sensitive data from another part of the application, including local files served via registerFileProtocol or remote resources fetched via registerHttpProtocol. This capability effectively bypasses the Same-Origin Policy, a cornerstone of web security that prevents malicious scripts on one page from obtaining access to sensitive information on another page. The risk is particularly acute in scenarios where untrusted content is loaded alongside trusted internal application logic, as it allows for potential data exfiltration or unauthorized state manipulation across origin boundaries.
It is important to note the specific scope of this vulnerability. Applications are only affected if they explicitly register a custom scheme with supportFetchAPI enabled and corsEnabled disabled while also loading untrusted content in the same session. Schemes that are intentionally registered with corsEnabled enabled remain cross-origin readable by design, as this configuration aligns with standard web behavior where CORS policies govern access rather than blocking it entirely. Therefore, the vulnerability is not universal to all Electron applications but is contingent upon a specific and somewhat less common configuration setup involving custom protocols and mixed trust levels within the application session.
To mitigate this risk, developers must upgrade their Electron dependencies to versions 41.10.6, 42.9.2, 43.4.1, or later beta releases such as 44.0.0-beta.5 where these issues have been resolved. For applications that cannot immediately update, it is crucial to review the configuration of any custom URL schemes. If cross-origin access is not strictly required for a specific scheme, ensuring corsEnabled remains disabled while avoiding the loading of untrusted content in the same session can reduce exposure. Alternatively, if cross-origin access is necessary, explicitly enabling corsEnabled and implementing robust CORS policies with appropriate Access-Control-Allow-Origin headers provides a more secure and standard-compliant approach to managing resource sharing between origins.
From an industry standards perspective, this vulnerability aligns with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, as well as CWE-942, the Permissive Cross-domain Policy with Untrusted Domains. In terms of attack tactics, it relates to MITRE ATT&CK techniques involving Data from Local System or Browser-based Exfiltration, where attackers leverage browser features and misconfigurations to bypass security controls and access restricted data. Addressing this issue requires a holistic approach that combines timely patch management with rigorous configuration auditing to ensure that custom protocol handlers do not inadvertently weaken the application's overall security posture against cross-origin attacks.