Electron Named Window Vulnerability in window.open() Scoping

A vulnerability exists in Electron prior to versions 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5, where the window.open() function did not properly restrict named-window lookups to the opener's browsing context group. This flaw allows a renderer to manipulate an existing child window opened by a different renderer, provided both use the same target name. If the child window had more lenient webPreferences (through setWindowOpenHandler's overrideBrowserWindowOptions), the second renderer could exploit this by inheriting those permissions. This issue affects applications that open multiple top-level windows with varying trust levels and use setWindowOpenHandler to assign elevated webPreferences to child windows, such as a privileged preload script. Applications that maintain a single top-level window or do not elevate child window privileges are not impacted. Furthermore, apps that grant nodeIntegration: true or sandbox: false to child windows, against security best practices, could face arbitrary code execution risks.

Impact

Exploitation allows for navigation of child windows across different renderers, potentially leading to unauthorized access to elevated webPreferences and, in some cases, arbitrary code execution.

Remediation

To address this vulnerability, update Electron to version 39.8.5, 40.8.5, 41.1.0, or 42.0.0-alpha.5. For applications that cannot be updated, consider denying window.open() in renderers that load untrusted content by returning { action: 'deny' } from setWindowOpenHandler. Avoid granting child windows more permissive webPreferences than their opener.