CVE-2026-102674

Electron is a framework for writing cross-platform desktop applications. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6.

Electron is a framework for building desktop apps. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, an Electron <webview> guest could enable nodeIntegrationInWorker for its Web Workers even when the unsandboxed embedder had Node.js integration disabled. This allowed untrusted guest content to create a Node-enabled worker with more privilege than the embedder granted.

Electron prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5 had an issue where responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme with supportFetchAPI enabled but corsEnabled disabled could remain script-readable across origins. This residual issue completes the remediation for CVE-2026-70604.

Electron prior to 41.10.4, 42.5.2, and 43.0.0 did not pass inherited HTML sandbox restrictions to popups opened from a sandboxed iframe through Electron's OpenURLFromTab navigation path, including links using target="_blank" or a middle-click. An untrusted iframe using the allow-scripts allow-popups configuration could open a popup with the embedding application's full origin, exposing that origin's cookies, storage, and same-origin scripting capabilities.

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.