Electron vulnerabilities

Electron applications on macOS using Squirrel.Mac-based automatic updates are vulnerable to a local race in the privileged ShipIt helper prior to 39.8.10, 41.10.5, and 42.0.0-beta.2. The helper did not bind the validated update target to one canonical application-bundle path, allowing a local attacker to redirect the root-level write and overwrite another application's files.

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.6, 42.9.2, 43.4.1, and 44.0.0-beta.5 did not inherit active HTML sandbox restrictions for windows opened from a sandboxed top-level document. Untrusted content in such a document that was allowed to open popups could create a window with the Electron application's full origin instead of the restricted origin intended by the sandbox.

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.

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.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.10, 40.9.3, 41.4.0, and 42.0.0, a custom scheme registered with supportFetchAPI: true but without corsEnabled: true was not subject to CORS enforcement. A page loaded from a remote origin could therefore fetch() or XMLHttpRequest that scheme cross-origin and read the full response body. Apps that serve sensitive data from such a scheme and load remote or untrusted content in a renderer are affected.

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.

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.9, 40.9.2, 41.2.2, and 42.0.0-beta.5, apps that expose Promise-returning functions to web content via contextBridge may be vulnerable to a context isolation bypass. Untrusted web content could obtain access to the isolated preload world and, through it, every capability the preload script has. In renderers without a sandbox, or with nodeIntegration enabled, this may escalate to Node.js access.

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, the native autofill popup could be positioned by a cross-origin iframe outside that iframe's bounds, over the embedding page's UI, enabling clickjacking or spoofing of trusted UI. Apps are only affected if they embed untrusted content in iframes within windows that also display trusted UI. Apps that do not embed untrusted third-party content are not affected.

In Electron prior to 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1, serial-port and media permission checks made from an iframe passed the top-level frame origin to session.setPermissionCheckHandler instead of the requesting iframe origin. Origin-based handler logic could grant a cross-origin iframe device access intended only for the top-level origin.

Electron is a framework for writing cross-platform desktop applications. Prior to 39.8.10, 40.9.0, 41.2.1, and 42.0.0-beta.3, offscreen rendering frame data received from the GPU process was not fully validated by the main process. A compromised GPU process could cause the main process to read out-of-bounds memory while producing paint event images, disclosing memory or crashing the app.

In Electron prior to 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3, the check Electron uses on macOS to confirm it was launched by a same-signed parent process could be bypassed by a local process. Apps that enable fuse-based hardening restricting ELECTRON_RUN_AS_NODE and NODE_OPTIONS to same-signed parents rely on this check, and a local attacker could bypass it and run code inside the signed app, inheriting its TCC permissions and keychain access.

In Electron prior to versions 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5, a vulnerability was found in the clipboard.readImage() function. If the clipboard contains image data that fails to decode, passing a null bitmap to image construction causes a controlled abort and process crash. Only apps calling clipboard.readImage() are affected.

Electron before versions 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5 contains a vulnerability where a child window can be navigated by an unrelated renderer if both use the same target name. This can lead to privilege escalation, and if nodeIntegration is enabled or sandbox disabled, to remote code execution.

Electron versions from 39.0.0-alpha.1 to before 39.8.0, 40.0.0-alpha.1 to before 40.7.0, and 41.0.0-alpha.1 to before 41.0.0-beta.8 contain a context isolation bypass vulnerability. Apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable. An attacker who can execute JavaScript in the main world (e.g., via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script.

Vulnerability in Electron (versions before 38.8.6, 39.8.1, 40.8.0, 41.0.0-beta.8) on macOS. The app.moveToApplicationsFolder() function uses AppleScript that improperly handles certain characters in the path, potentially leading to arbitrary AppleScript execution when the user accepts the prompt.

In Electron prior to versions 38.8.6, 39.8.1, 40.8.1, and 41.0.0, a service worker running in a session can spoof reply messages on the internal IPC channel used by webContents.executeJavaScript() and related methods, causing the main-process promise to resolve with attacker-controlled data.

In Electron prior to versions 38.8.6, 39.8.1, 40.8.1, and 41.0.0, when an iframe requests fullscreen, pointerLock, keyboardLock, openExternal, or media permissions, the origin passed to session.setPermissionRequestHandler() was the top-level page's origin rather than the requesting iframe's origin. Apps that grant permissions based on the origin parameter may inadvertently grant permissions to embedded third-party content.

Electron before versions 38.8.6, 39.8.1, 40.8.1, and 41.0.0 on macOS and Linux has an out-of-bounds heap read vulnerability when parsing a crafted second-instance message if the app calls app.requestSingleInstanceLock(). Leaked memory can be delivered to the app's second-instance event handler. This issue is limited to processes running as the same user as the Electron app. Windows is not affected.

In Electron prior to versions 38.8.6, 39.8.4, 40.8.4, and 41.0.0, the nodeIntegrationInWorker setting was not correctly scoped. In certain process-sharing scenarios, workers spawned in frames with nodeIntegrationInWorker: false could still receive Node.js integration. Only apps that enable nodeIntegrationInWorker are affected.

Electron before versions 39.8.1, 40.7.0, and 41.0.0 has a use-after-free vulnerability in apps using offscreen rendering and allowing child windows via window.open(). Destroying the parent WebContents while a child window is open can lead to a crash or memory corruption.

Electron on Windows does not validate the protocol name in app.setAsDefaultProtocolClient() before writing to the registry. Apps passing untrusted input as the protocol name may allow an attacker to write to arbitrary registry subkeys, potentially hijacking existing protocol handlers.

Electron, a framework for building desktop applications, has a use-after-free vulnerability when apps allow downloads and programmatically destroy sessions. If a session is torn down while a native save-file dialog is open, dismissing the dialog dereferences freed memory, potentially leading to a crash or memory corruption. This affects versions prior to 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.

Electron prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8 is vulnerable to a use-after-free when handling fullscreen, pointer-lock, or keyboard-lock permission requests if the app registers an asynchronous `session.setPermissionRequestHandler()`. If the requesting frame navigates or the window closes while the permission handler is pending, invoking the stored callback dereferences freed memory, which may lead to a crash or memory corruption.

Electron before versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8 contains a use-after-free vulnerability in the powerMonitor module. After the PowerMonitor object is garbage-collected, OS resources retain dangling references, leading to crashes or memory corruption on session events (Windows) or system shutdown (macOS).

Electron prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8 has an undocumented commandLineSwitches webPreference that allows arbitrary switches to be appended to the renderer process command line. Apps constructing webPreferences from untrusted configuration objects may allow an attacker to disable renderer sandboxing or web security controls.

Electron on Windows fails to quote the executable path when writing to the Run registry key, allowing an attacker with write access to an ancestor directory to replace the startup executable.

Electron, a framework for building desktop applications, has an HTTP response header injection vulnerability. Apps that register custom protocol handlers via protocol.handle() or modify response headers via webRequest.onHeadersReceived may be vulnerable if attacker-controlled input is reflected into a response header name or value. This affects versions prior to 38.8.6, 39.8.3, 40.8.3, and 41.0.3.

In Electron before versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, the select-usb-device event callback does not validate the chosen device ID against the filtered list. An app whose handler can be influenced to select a device outside the filtered set may grant access to an unauthorized USB device.