GHSA-f3pv-wv63-48x8 Electron: Named window.open targets not scoped to the opener's browsing context

• npm electron: < 39.8.5 → fixed in 39.8.5 • npm electron: >= 40.0.0-alpha.1, < 40.8.5 → fixed in 40.8.5 • npm electron: >= 41.0.0-alpha.1, < 41.1.0 → fixed in 41.1.0 • npm electron: >= 42.0.0-alpha.1, < 42.0.0-alpha.5 → fixed in 42.0.0-alpha.5

Impact When a renderer calls `window.open()` with a target name, Electron did not correctly scope the named-window lookup to the opener's browsing context group. A renderer could navigate an existing child window that was opened by a different, unrelated renderer if both used the same target name. If that existing child was created with more permissive `webPreferences` (via `setWindowOpenHandler`'s `overrideBrowserWindowOptions`), content loaded by the second renderer inherits those permissions. Apps are only affected if they open multiple top-level windows with differing trust levels and use `setWindowOpenHandler` to grant child windows elevated `webPreferences` such as a privileged preload script. Apps that do not elevate child window privileges, or that use a single top-level window, are not affected. Apps that additionally grant `nodeIntegration: true` or `sandbox: false` to child windows (contrary to the security recommendations) may be exposed to arbitrary code execution. Workarounds Deny `window.open()` in renderers that load untrusted content by returning `{ action: 'deny' }` from `setWindowOpenHandler`. Avoid granting child windows more permissive `webPreferences` than their opener. Fixed Versions • `42.0.0-alpha.5` • `41.1.0` • `40.8.5` • `39.8.5` For more information If you have any questions or comments about this advisory, email us at [email protected]