Impact

The cache Electron keeps for sandboxed preload scripts did not verify that a cached entry matched the preload it was served for. A compromised renderer could use this to run its own code in the preload context on a later load.

Apps are only affected if they load untrusted content. Apps that do not load untrusted content are not affected.

Workarounds

There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions

44.0.0-beta.6 43.5.0 42.10.0

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact

A <webview> could enable Node.js integration in its Web Workers even when its embedder had Node.js integration disabled, giving guest content more privilege than the embedder allowed.

Apps are only affected if they enable the <webview> tag and the embedder is unsandboxed. Apps that do not use <webview>, or that keep the embedder sandboxed, are not affected.

Workarounds

Remove nodeIntegrationInWorker from the guest preferences in a will-attach-webview handler, or do not enable the <webview> tag when loading untrusted content.

Fixed Versions

44.0.0-beta.5 43.4.1 42.9.2 41.10.6

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact

Responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme registered with supportFetchAPI: true but without corsEnabled: true could be read cross-origin by web content. This completes the fix for CVE-2026-70604.

Apps are only affected if they register such a scheme, serve it through one of those handlers, and load untrusted content. Apps that set corsEnabled: true, or that do not load untrusted content, are not affected.

Workarounds

Set corsEnabled: true on the scheme, or do not load untrusted content in windows that can reach it.

Fixed Versions

44.0.0-beta.5 43.4.1 42.9.2 41.10.6

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact

Windows opened from a sandboxed top-level document did not inherit that document's HTML sandbox restrictions, so content that was meant to run sandboxed could open a window with the app's full origin. GHSA-hq2x-r82h-9wj4 covers the same issue for sandboxed iframes.

Apps are only affected if they render untrusted content in a sandboxed top-level document that allows popups. Apps that deny popups from untrusted content with setWindowOpenHandler are not affected.

Workarounds

Return { action: 'deny' } from setWindowOpenHandler for windows opened by untrusted content.

Fixed Versions

44.0.0-beta.5 43.4.1 42.9.2 41.10.6

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact

Popups opened from a sandboxed iframe through a link (for example target="blank" or a middle-click) did not inherit the iframe's HTML sandbox restrictions. Content that was meant to run sandboxed could open a popup with the embedding app's full origin, gaining access to that origin's cookies, storage, and same-origin scripting.

Apps are only affected if they embed untrusted content in iframes sandboxed with allow-scripts allow-popups. Apps that do not embed untrusted content in sandboxed iframes are not affected.

Workarounds

Use setWindowOpenHandler on the parent WebContents to deny or constrain popups opened from sandboxed frames, or do not apply allow-popups to sandboxed iframes that render untrusted content.

Fixed Versions

43.0.0 42.5.2 41.10.4

For more information

If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact 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's sandbox state was also not made available to the app's permission handlers.

Apps are only affected if they render untrusted content in sandboxed iframes and grant the openExternal permission (granted by default when no setPermissionRequestHandler is installed). Apps whose permission handler denies openExternal for untrusted content are not affected.

Workarounds Install a setPermissionRequestHandler that denies the openExternal permission for untrusted content.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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 this to execute native code outside the sandbox.

Apps are only affected if DevTools is opened for windows exposed to untrusted content or untrusted DevTools extensions. Apps that do not open DevTools in that context are not affected.

Workarounds Do not open DevTools for windows that load untrusted content, and do not load untrusted DevTools extensions.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.2 39.8.9

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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. Apps that only accept primitive arguments, or that validate object arguments, are not affected.

Workarounds Validate objects received from untrusted content with own-property checks (Object.hasOwn), or copy them onto a null-prototype object before use.

Fixed Versions 42.0.0-beta.4 41.2.2 40.9.2 39.8.9

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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.

Apps are only affected if untrusted input can reach the mode argument of openDevTools(), or if untrusted content can call openDevTools() on a <webview> it embeds. Apps that only ever pass a fixed dock mode are not affected.

Workarounds Only pass fixed, allowlisted values (right, bottom, undocked, detach) as the DevTools mode, and do not expose openDevTools to untrusted content.

Fixed Versions 42.0.0-beta.1 41.2.0 40.9.0 39.8.7

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact A sandboxed iframe without the allow-popups keyword could still open a new window (or trigger setWindowOpenHandler) with no user interaction, 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 to prevent window creation are affected. Apps that deny window creation in setWindowOpenHandler, or that do not embed untrusted content in sandboxed iframes, are not affected.

Workarounds Return { action: 'deny' } from setWindowOpenHandler for any content you do not trust, rather than relying on the iframe sandbox alone.

Fixed Versions 42.0.1 41.10.3 39.8.10

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact Some window options supplied by web content in the window.open() features string were applied 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.

Apps are only affected if untrusted content can call window.open() and the app does not override child window options via setWindowOpenHandler. Apps that deny window.open() for untrusted content, or set overrideBrowserWindowOptions explicitly, are not affected.

Workarounds Return { action: 'deny' } from setWindowOpenHandler for untrusted content, or supply overrideBrowserWindowOptions so every window option is set explicitly.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact When a custom protocol handler returned a ProtocolResponse with a url and no session, Electron made the upstream request through defaultSession instead of the session that handled the protocol. A cached response could then be reused across otherwise isolated session partitions.

Apps that use ProtocolResponse.url, omit ProtocolResponse.session, and rely on separate sessions to isolate content are affected. Apps that set an explicit session, or that do not isolate content across sessions, are not affected.

Workarounds Set ProtocolResponse.session explicitly so the request uses the intended session's cache.

Fixed Versions 43.0.0 42.5.1 41.9.1 40.10.6

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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 (the default) and expose the response body. Apps that only request fixed, trusted URLs are not affected.

Workarounds Set redirect: 'error' or redirect: 'manual' on requests to untrusted URLs and validate any redirect target before following it.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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, rather than the read being blocked.

Apps that serve sensitive data from such a scheme and load remote or untrusted content in a renderer are affected. Apps that set corsEnabled: true, or that do not load untrusted content, are not affected.

Workarounds Set corsEnabled: true on schemes that must enforce CORS, and validate the request Origin in your protocol handler before returning sensitive data.

Fixed Versions 42.0.0 41.4.0 40.9.3 39.8.10

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact shell.openPath() did not reject paths containing embedded null bytes. Apps that perform string-only validation of file paths (for example, 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 to shell.openPath() and rely on string-based validation without a filesystem check. Node's fs APIs already reject paths containing null bytes, so apps that call fs.existsSync(), fs.stat(), or similar before shell.openPath() are not affected. Apps that do not call shell.openPath() with untrusted input are not affected.

Workarounds Reject any path containing a null byte before passing it to shell.openPath(): js if (filePath.includes('\0')) throw new Error('invalid path');

Fixed Versions 42.0.0-beta.1 41.1.1 40.9.0 39.8.6

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact 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. Apps that do not load extensions, or that use a single session, are not affected.

Workarounds Only load extensions from sources you trust; do not rely on session separation alone to contain an extension.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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.

Apps are affected if they expose Promise-returning functions via contextBridge — the standard pattern for wrapping ipcRenderer.invoke — in windows that load untrusted content. Apps that never load untrusted content in those windows are not affected.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 42.0.0-beta.5 41.2.2 40.9.2 39.8.9

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact 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.

Workarounds Do not embed untrusted content in iframes inside windows that display trusted UI.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact For serial-port and media (camera / microphone) permission checks made from an iframe, the requestingOrigin passed to session.setPermissionCheckHandler was the top-level frame's origin rather than the requesting frame's. Origin-based handler logic could therefore grant a cross-origin iframe device access intended only for the top-level origin.

Apps are only affected if they use setPermissionCheckHandler with origin-based logic and embed cross-origin iframes with delegated device permissions. Apps that base the decision on details.securityOrigin, or that do not embed such iframes, are not affected.

Workarounds Check details.securityOrigin instead of requestingOrigin for these permissions, or do not delegate device permissions to untrusted iframes.

Fixed Versions 42.0.0-beta.1 41.2.0 40.9.0 39.8.7

For more information If you have any questions or comments about this advisory, email Electron at security@electronjs.org

Impact In offscreen rendering mode, 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.

Apps are only affected if they use offscreen rendering (webPreferences.offscreen) and an attacker has separately gained code execution in the GPU process. Apps that do not use offscreen rendering are not affected.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.10

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact On macOS, the check Electron uses to confirm it was launched by a same-signed parent process could be bypassed by a local process. Apps that enable the fuse-based hardening restricting ELECTRONRUNASNODE and NODEOPTIONS to same-signed parents rely on this check; a local attacker could bypass it and run their own code inside the signed app, inheriting its TCC permissions and keychain access.

Apps are only affected if they enable those macOS fuse-based restrictions. Apps that do not enable them are not affected.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 42.0.0-beta.3 41.2.1 40.9.0 39.8.8

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact Apps that call clipboard.readImage() may be vulnerable to a denial of service. If the system clipboard contains image data that fails to decode, the resulting null bitmap is passed unchecked to image construction, triggering a controlled abort and crashing the process.

Apps are only affected if they call clipboard.readImage(). Apps that do not read images from the clipboard are not affected. This issue does not allow memory corruption or code execution.

Workarounds Validate that the clipboard contains image data via clipboard.availableFormats() before calling clipboard.readImage(). Note this only narrows the window — upgrading to a fixed version is recommended.

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 security@electronjs.org

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 security@electronjs.org

Impact Apps that use offscreen rendering with GPU shared textures may be vulnerable to a use-after-free. Under certain conditions, the release() callback provided on a paint event texture can outlive its backing native state, and invoking it after that point dereferences freed memory in the main process, which may lead to a crash or memory corruption.

Apps are only affected if they use offscreen rendering with webPreferences.offscreen: { useSharedTexture: true }. Apps that do not enable shared-texture offscreen rendering are not affected.

Workarounds Ensure texture.release() is called promptly after the texture has been consumed, before the texture object becomes unreachable.

Fixed Versions 42.0.0-alpha.5 41.1.0 40.8.5 39.8.5

For more information If there are any questions or comments about this advisory, send an email to security@electronjs.org

Impact Apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script.

Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected.

Workarounds Do not pass VideoFrame objects across contextBridge. If an app needs to transfer video frame data, serialize it to an ArrayBuffer or ImageBitmap before bridging.

Fixed Versions 41.0.0-beta.8 40.7.0 39.8.0

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact On macOS, app.moveToApplicationsFolder() used an AppleScript fallback path that did not properly handle certain characters in the application bundle path. Under specific conditions, a crafted launch path could lead to arbitrary AppleScript execution when the user accepted the move-to-Applications prompt.

Apps are only affected if they call app.moveToApplicationsFolder(). Apps that do not use this API are not affected.

Workarounds There are no app side workarounds, developers must update to a patched version of Electron.

Fixed Versions 41.0.0-beta.8 40.8.0 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact A service worker running in a session could 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.

Apps are only affected if they have service workers registered and use the result of webContents.executeJavaScript() (or webFrameMain.executeJavaScript()) in security-sensitive decisions.

Workarounds Do not trust the return value of webContents.executeJavaScript() for security decisions. Use dedicated, validated IPC channels for security-relevant communication with renderers.

Fixed Versions 41.0.0 40.8.1 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact 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 or webContents.getURL() may inadvertently grant permissions to embedded third-party content.

The correct requesting URL remains available via details.requestingUrl. Apps that already check details.requestingUrl are not affected.

Workarounds In your setPermissionRequestHandler, inspect details.requestingUrl rather than the origin parameter or webContents.getURL() when deciding whether to grant fullscreen, pointerLock, keyboardLock, openExternal, or media permissions.

Fixed Versions 41.0.0 40.8.1 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact On macOS and Linux, apps that call app.requestSingleInstanceLock() were vulnerable to an out-of-bounds heap read when parsing a crafted second-instance message. Leaked memory could 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.

Apps that do not call app.requestSingleInstanceLock() are not affected. Windows is not affected by this issue.

Workarounds There are no app side workarounds, developers must update to a patched version of Electron.

Fixed Versions 41.0.0 40.8.1 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact The nodeIntegrationInWorker webPreference was not correctly scoped in all configurations. In certain process-sharing scenarios, workers spawned in frames configured with nodeIntegrationInWorker: false could still receive Node.js integration.

Apps are only affected if they enable nodeIntegrationInWorker. Apps that do not use nodeIntegrationInWorker are not affected.

Workarounds Avoid enabling nodeIntegrationInWorker in apps that also open child windows or embed content with differing webPreferences.

Fixed Versions 41.0.0 40.8.4 39.8.4 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org