https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 14:20:08 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-290878 EUVD-2026-290878 https://cve.radiocsirt.org/vuln/euvd-2026-290878 https://cve.radiocsirt.org/vuln/fkie_cve-2026-34765 <p>Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5, when a renderer calls window.open() with a target name, Electron did not correctly scope the named-window lookup to the opener&#39;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&#39;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. This vulnerability is fixed in 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5.</p> <p>Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5, when a renderer calls window.open() with a target name, Electron did not correctly scope the named-window lookup to the opener&#39;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&#39;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. This vulnerability is fixed in 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-34765 https://cve.radiocsirt.org/vuln/ghsa-f3pv-wv63-48x8 <p><strong>Affected:</strong> npm: electron</p> <p>### Impact When a renderer calls `window.open()` with a target name, Electron did not correctly scope the named-window lookup to the opener&#39;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`&#39;s `overrideBrowserWindowOptions`), content loaded by the second renderer inherits those permissions.</p> <p>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.</p> <p>Apps that additionally grant `nodeIntegration: true` or `sandbox: false` to child windows (contrary to the [security recommendations](https://www.electronjs.org/docs/latest/tutorial/security)) may be exposed to arbitrary code execution.</p> <p>### Workarounds Deny `window.open()` in renderers that load untrusted content by returning `{ action: &#39;deny&#39; }` from `setWindowOpenHandler`. Avoid granting child windows more permissive `webPreferences` than their opener.</p> <p>### Fixed Versions * `42.0.0-alpha.5` * `41.1.0` * `40.8.5` * `39.8.5`</p> <p>### For more information If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@el…</p> <p><strong>Affected:</strong> npm: electron</p> <p>### Impact When a renderer calls `window.open()` with a target name, Electron did not correctly scope the named-window lookup to the opener&#39;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`&#39;s `overrideBrowserWindowOptions`), content loaded by the second renderer inherits those permissions.</p> <p>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.</p> <p>Apps that additionally grant `nodeIntegration: true` or `sandbox: false` to child windows (contrary to the [security recommendations](https://www.electronjs.org/docs/latest/tutorial/security)) may be exposed to arbitrary code execution.</p> <p>### Workarounds Deny `window.open()` in renderers that load untrusted content by returning `{ action: &#39;deny&#39; }` from `setWindowOpenHandler`. Avoid granting child windows more permissive `webPreferences` than their opener.</p> <p>### Fixed Versions * `42.0.0-alpha.5` * `41.1.0` * `40.8.5` * `39.8.5`</p> <p>### For more information If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@el…</p> https://cve.radiocsirt.org/vuln/ghsa-f3pv-wv63-48x8