Impact
A set of eMudhra intermediate certificates were compromised and are being blocked by browsers and other TLS clients. This Electron update adds the same block to both Chromium networking and Node.js tls, https and fetch. On earlier versions, an attacker holding a certificate issued through these intermediates and able to intercept network traffic could impersonate a TLS server to an app.
Apps are only affected if they make TLS connections over a network an attacker can intercept. Apps that make no network connections are not affected.
Other software has shipped the same mitigation, including Go (CVE-2026-111943) and Firefox (CVE-2026-113470).
Workarounds
There are no app side workarounds, you must update to a patched version of Electron.
Fixed Versions
45.0.0-beta.6 44.9.1 43.8.1 42.11.16
For more information
If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact In offscreen rendering mode on macOS, 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. GHSA-pfmc-3mgc-p6fp covers the same issue on the other capture paths.
Apps are only affected if they use offscreen rendering (webPreferences.offscreen) on macOS 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 45.0.0-alpha.9 44.4.3 43.7.3 42.11.6
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact Frame data received from the GPU process for webContents.beginFrameSubscription 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 the captured frame images, disclosing memory or crashing the app.
Apps are only affected if they use webContents.beginFrameSubscription and an attacker has separately gained code execution in the GPU process. Apps that do not subscribe to captured frames are not affected.
Workarounds There are no app side workarounds, you must update to a patched version of Electron.
Fixed Versions 45.0.0-alpha.9 44.4.3 43.7.3 42.11.6
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 could be attributed to a document other than the one that asked for them, so the requestingUrl passed to session.setPermissionRequestHandler was a trusted origin for a launch untrusted content had requested. An origin-based handler could therefore let untrusted content launch an OS-registered external application.
Apps are only affected if they grant openExternal based on the requesting origin and let untrusted content open or navigate windows. Apps whose permission handler denies openExternal for untrusted content are not affected.
Workarounds Deny the openExternal permission for untrusted content, or deny the windows it opens with setWindowOpenHandler.
Fixed Versions 45.0.0-alpha.5 44.3.0 43.7.0 42.11.3
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact For hid and usb permission checks made from an iframe, session.setPermissionCheckHandler was given the top-level frame's origin and details instead of the requesting frame's. Apps that allow these permissions based on origin could grant an embedded frame access intended for the top-level page.
You're only affected if you use setPermissionCheckHandler with origin-based logic for hid or usb and embed cross-origin iframes with allow="hid" or allow="usb". Apps that don't delegate those features to untrusted iframes are not affected.
Workarounds Don't add allow="hid" / allow="usb" to untrusted iframes, or make the decision in your select-hid-device / select-usb-device handler using details.frame.
Fixed Versions 45.0.0-alpha.5 44.3.0 43.7.0 42.11.3
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact For pointerLock permission requests made from some cross-origin iframes, session.setPermissionRequestHandler() was given the top-level frame's requestingUrl and isMainFrame instead of the requesting frame's. Apps that grant pointer lock based on the requesting origin could grant it to embedded content under the top-level page's identity.
Apps are only affected if they embed untrusted content in iframes and decide pointerLock requests by origin in setPermissionRequestHandler. Apps that do not embed untrusted content, or that deny pointerLock for it, are not affected.
Workarounds Deny the pointerLock permission for web contents that embed untrusted frames.
Fixed Versions 45.0.0-alpha.13 44.5.0 43.7.6 42.11.9
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact chrome.tabs.query() returned each tab's url and title to extensions that held neither the tabs permission nor matching host permissions, so any loaded extension could read the URL and title of every webContents in its session.
Apps are only affected if they load extensions (session.extensions.loadExtension) that they do not fully trust. Apps that load no extensions, or only trusted ones, are not affected.
Workarounds Do not load untrusted or unvalidated extensions. In general you should only load trusted extensions.
Fixed Versions 45.0.0-alpha.4 44.1.1 43.5.1 42.11.1
For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Impact
Pages opened into a new window from a link were loaded as if the app itself had navigated there rather than the page that contained the link, so the request was treated as same-site: SameSite=Strict cookies were sent and Sec-Fetch-Site did not identify the initiating page. Content shown in the app could use this to make a credentialed top-level request to another site that relies on SameSite cookies as a CSRF defence.
Apps are only affected if they load untrusted content and allow it to open new windows. Apps that deny new windows from untrusted content with setWindowOpenHandler are not affected.
Workarounds
Return { action: 'deny' } from setWindowOpenHandler for windows opened by untrusted content.
Fixed Versions
45.0.0-alpha.6 44.3.0 43.7.0 42.11.3
For more information
If you have any questions or comments about this advisory, email us at security@electronjs.org
End of life: 4/27/2027, Latest version: 45.2.2
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
End of life: 3/2/2027, Latest version: 44.10.2
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 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
End of life: 1/5/2027, Latest version: 43.8.7
End of life: 10/20/2026, Latest version: 42.11.18
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 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, 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. This issue has been patched in versions 39.8.0, 40.7.0, and 41.0.0-beta.8.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 39.8.1, 40.7.0, and 41.0.0, apps that use offscreen rendering and allow child windows via window.open() may be vulnerable to a use-after-free. If the parent offscreen WebContents is destroyed while a child window remains open, subsequent paint frames on the child dereference freed memory, which may lead to a crash or memory corruption. Apps are only affected if they use offscreen rendering (webPreferences.offscreen: true) and their setWindowOpenHandler permits child windows. Apps that do not use offscreen rendering, or that deny child windows, are not affected. This issue has been patched in versions 39.8.1, 40.7.0, and 41.0.0.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, apps that register an asynchronous session.setPermissionRequestHandler() may be vulnerable to a use-after-free when handling fullscreen, pointer-lock, or keyboard-lock permission requests. 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. Apps that do not set a permission request handler, or whose handler responds synchronously, are not affected. This issue has been patched in versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, an undocumented commandLineSwitches webPreference allowed arbitrary switches to be appended to the renderer process command line. Apps that construct webPreferences by spreading untrusted configuration objects may inadvertently allow an attacker to inject switches that disable renderer sandboxing or web security controls. Apps are only affected if they construct webPreferences from external or untrusted input without an allowlist. Apps that use a fixed, hardcoded webPreferences object are not affected. This issue has been patched in versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.
End of life: 8/24/2026, Latest version: 41.10.7
End of life: 7/1/2026, Latest version: 40.10.6
End of life: 5/5/2026, Latest version: 39.8.10
End of life: 3/10/2026, Latest version: 38.8.6
End of life: 1/15/2026, Latest version: 37.10.3
End of life: 10/27/2025, Latest version: 36.9.5
End of life: 9/2/2025, Latest version: 35.7.5