CVE-2026-70604

A vulnerability in Electron prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3 occurs because extension tab and scripting APIs were not scoped to the extension's own session. A malicious or compromised extension loaded into one session could navigate, script, and read from windows belonging to a different session. Apps are only affected if they load Chrome extensions via session.loadExtension and rely on separate sessions to isolate that extension from other content.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3, requests to open external protocol URLs from web content did not take iframe sandbox restrictions into account, so a sandboxed iframe could cause an OS-registered external application to be launched. The frame sandbox state was also not made available to the app permission handlers, affecting apps that render untrusted content in sandboxed iframes and grant the openExternal permission by default when no setPermissionRequestHandler is installed.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3, the DevTools reveal in file manager action could launch the target file rather than reveal it. An attacker with a separate means of running script inside the DevTools frontend, such as a malicious DevTools extension, could use showItemInFolder handling to execute native code outside the sandbox when DevTools is opened for windows exposed to untrusted content or untrusted DevTools extensions.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4, objects copied across the contextBridge boundary from untrusted content could carry an attacker-influenced prototype, enabling prototype-pollution-style attacks against preload code despite context isolation being enabled. Apps are only affected if their preload code accepts object arguments from untrusted content and reads properties from them without own-property checks, while apps that only accept primitive arguments or validate object arguments are not affected.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1, the mode option of webContents.openDevTools() was not sanitized before use by the DevTools frontend. If an attacker can influence this value, script under their control may run in the DevTools context, which in unsandboxed configurations has access to Node.js, including when untrusted input reaches the mode argument of openDevTools() or untrusted content calls openDevTools() on a webview it embeds.

Electron before versions 39.8.10, 41.10.3, and 42.0.1 allowed a sandboxed iframe without the allow-popups keyword to open new windows or trigger setWindowOpenHandler without user interaction. This occurs because new-window navigations taking the OpenURL path did not apply the iframe sandbox popup restriction. Apps that embed untrusted content in sandboxed iframes and rely on the absence of allow-popups are affected, while apps that deny window creation in setWindowOpenHandler or do not embed untrusted content are not.

Electron (before versions 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3) applies some window options supplied by web content in the window.open() features string to the new BrowserWindow without an allowlist. Untrusted content could set window options it should not control, including options that cause the main process to access attacker-chosen file or network paths, when untrusted content can call window.open() and the app does not override child window options via setWindowOpenHandler or overrideBrowserWindowOptions.

A vulnerability in Electron prior to 40.10.6, 41.9.1, 42.5.1, and 43.0.0 occurs when a custom protocol handler returns a ProtocolResponse with a url and no session, causing the request to go through defaultSession instead of the session that handled the protocol. This can lead to cached responses being reused across isolated session partitions. Apps using ProtocolResponse.url, omitting ProtocolResponse.session, and relying on separate sessions are affected.

A vulnerability in Electron prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3 occurs when following HTTP redirects, net.fetch() and net.request() did not restrict which schemes a redirect could target. A remote server could redirect a request to a local resource, and if the app returns or forwards the response body, local file contents could be disclosed. Apps are only affected if they make net requests to attacker-influenced URLs with redirects followed and expose the response body.

A vulnerability in Electron prior to 39.8.6, 40.9.0, 41.1.1, and 42.0.0-beta.1 occurs because shell.openPath() did not reject paths containing embedded null bytes. Apps that perform string-only validation of file paths, such as checking the file extension, before passing them to shell.openPath() could be bypassed, allowing an attacker-controlled path to open a different file than the one that passed validation. Apps are only affected if they pass paths derived from untrusted input and rely on string-based validation without a filesystem check.