Electron versions prior to 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5 fail to isolate named window targets within the same browsing context group. A renderer can navigate an existing child window that was opened by a different, unrelated renderer if both specify the same target name. Because the existing child may have been created with elevated webPreferences—such as a privileged preload script or node integration—this mis‑scoping allows the second renderer to implicitly inherit those higher permissions. An attacker who can control a renderer that opens a target name shared with a privileged window can potentially execute arbitrary code in the context of that elevated child window, leading to serious confidentiality and integrity risks.

The issue affects applications built with the Electron framework before the specified fixed releases. Impacted apps are those that open multiple top‑level windows with differing trust levels and employ the setWindowOpenHandler API to grant child windows elevated webPreferences. Applications that do not elevate child window privileges, or that use only a single top‑level window, are not affected. If an app also grants nodeIntegration:true or sandbox:false to child windows—contrary to recommended security practices—then the vulnerability could lead to arbitrary code execution.

The CVSS score of 6.0 indicates moderate severity. No EPSS score is available, and the vulnerability is not listed in KEV. The attack vector is likely local, requiring the attacker to influence the renderer that opens the shared target name. Since the flaw depends on developer configuration choices rather than a generic exploit, successful exploitation would require that an application opens multiple windows with differing permissions and uses the same named target across those windows. Consequently, the risk is significant for misconfigured Electron applications but limited for those following the default security guidelines.