CVE-2026-102674 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, windows opened from a sandboxed top-level document did not inherit that document's active HTML sandbox restrictions. Untrusted content in a sandboxed top-level document that was permitted to open popups could therefore create a window with the Electron application's full origin instead of the restricted origin intended by the sandbox. Applications that deny such popups with setWindowOpenHandler are not affected. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/29/2026
Electron serves as a prominent framework for developing cross-platform desktop applications by leveraging web technologies such as JavaScript, HTML, and CSS. A critical security flaw was identified in versions prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5 regarding the handling of sandboxed contexts. The vulnerability stems from a failure in the inheritance mechanism for HTML sandbox restrictions when new windows are spawned from a top-level document that is already under strict sandboxing policies. This architectural oversight allows untrusted content operating within a restricted environment to bypass intended security boundaries through window manipulation techniques.
The technical core of this flaw lies in how Electron manages origin isolation and privilege escalation during the creation of child windows. When an application employs HTML sandbox attributes to restrict capabilities such as script execution, form submission, or plugin loading for specific web views, these restrictions are designed to contain potential malicious payloads within a limited scope. However, if content within such a sandboxed top-level document utilizes permitted popup mechanisms to open new browser windows, the resulting window does not inherit the parent's active HTML sandbox flags. Instead, the newly created window defaults to the Electron application's full origin context. This effectively grants the untrusted content elevated privileges that were explicitly denied in its source environment, creating a privilege escalation vector where restricted code gains access to unrestricted resources and APIs.
The operational impact of this vulnerability is significant for applications relying on sandboxing to mitigate risks from third-party or user-generated web content. An attacker who can inject malicious scripts into a sandboxed view could exploit this behavior to open a new window that operates with full application privileges. This allows the extraction of sensitive data, interaction with local file systems, execution of arbitrary code via Node.js integrations if enabled, and other actions typically blocked by the sandbox policy. The severity is particularly high in scenarios where applications display untrusted web content but assume that HTML sandboxes provide sufficient isolation against cross-origin attacks or privilege escalation through window handles.
It is crucial to note that this vulnerability does not affect applications that implement custom handlers for window creation using the setWindowOpenHandler API. By intercepting and controlling how new windows are opened, developers can enforce consistent security policies regardless of the parent document's sandbox status, thereby neutralizing the exploit path described here. For those relying on default behaviors or older implementation patterns, this flaw represents a direct bypass of intended containment strategies.
To mitigate this risk, organizations must upgrade Electron to version 41.10.6, 42.9.2, 43.4.1, or later stable releases where the inheritance logic has been corrected to ensure sandbox flags are properly propagated to child windows. Additionally, developers should review their window management strategies and consider implementing setWindowOpenHandler to maintain explicit control over origin contexts for all spawned windows. This aligns with industry standards such as CWE-250, which covers execution with unnecessary privileges, and relates to ATT&CK techniques involving privilege escalation through application logic flaws or sandbox escapes. Ensuring that security policies are consistently applied across the entire window hierarchy is essential for maintaining robust defense-in-depth postures in Electron-based applications.