Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
76 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
45.0.0-beta.644.9.142.11.1643.8.1· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-beta.6 (pre-release), 44.9.1, 43.8.1 or 42.11.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
44.3.045.0.0-alpha.642.11.343.7.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.6 (pre-release), 44.3.0, 43.7.0 or 42.11.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.11.943.7.645.0.0-alpha.1344.5.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.13 (pre-release), 44.5.0, 43.7.6 or 42.11.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
44.1.143.5.142.11.145.0.0-alpha.4· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.4 (pre-release), 44.1.1, 43.5.1 or 42.11.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.11.644.4.343.7.345.0.0-alpha.9· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.9 (pre-release), 44.4.3, 43.7.3 or 42.11.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.11.644.4.343.7.345.0.0-alpha.9· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.9 (pre-release), 44.4.3, 43.7.3 or 42.11.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
44.3.045.0.0-alpha.542.11.343.7.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.5 (pre-release), 44.3.0, 43.7.0 or 42.11.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
44.3.045.0.0-alpha.542.11.343.7.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 45.0.0-alpha.5 (pre-release), 44.3.0, 43.7.0 or 42.11.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact On macOS, Electron bundles the Squirrel.Mac auto-update framework, whose privileged ShipIt helper performs the final step of an update as root. A local attacker could cause that helper to overwrite a different application's files, as root, instead of the app that started the update. Exploitation requires local access to the machine. Apps are only affected on macOS if they ship Squirrel.Mac-based auto-updates. Apps on other platforms, or that do not use Squirrel.Mac auto-updates, 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.2 41.10.5 39.8.10 For more information If you have any questions or comments about this advisory, email us at security@electronjs.org
Recommended action: Upgrade to 42.0.0-beta.2 (pre-release), 41.10.5 or 39.8.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 43.0.0, 42.5.2 or 41.10.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.9.244.0.0-beta.543.4.141.10.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 44.0.0-beta.5 (pre-release), 43.4.1, 42.9.2 or 41.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.9.244.0.0-beta.543.4.141.10.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 44.0.0-beta.5 (pre-release), 43.4.1, 42.9.2 or 41.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.9.244.0.0-beta.543.4.141.10.6· Vendor fix available
Issue
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
Recommended action: Upgrade to 44.0.0-beta.5 (pre-release), 43.4.1, 42.9.2 or 41.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 44.0.0-beta.6 (pre-release), 43.5.0 or 42.10.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.0.0-beta.341.2.139.8.840.9.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.3 (pre-release), 41.2.1, 40.9.0 or 39.8.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.0.0-beta.339.8.940.9.241.2.1· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.3 (pre-release), 41.2.1, 40.9.2 or 39.8.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
39.8.940.9.242.0.0-beta.441.2.2· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.4 (pre-release), 41.2.2, 40.9.2 or 39.8.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
39.8.742.0.0-beta.140.9.041.2.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.1 (pre-release), 41.2.0, 40.9.0 or 39.8.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 42.0.1, 41.10.3 or 39.8.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.0.0-beta.341.2.139.8.840.9.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.3 (pre-release), 41.2.1, 40.9.0 or 39.8.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 43.0.0, 42.5.1, 41.9.1 or 40.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 42.0.0, 41.4.0, 40.9.3 or 39.8.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.0.0-beta.341.2.139.8.840.9.0· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.3 (pre-release), 41.2.1, 40.9.0 or 39.8.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
39.8.641.1.142.0.0-beta.140.9.0· Vendor fix available
Issue
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(): 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
Recommended action: Upgrade to 42.0.0-beta.1 (pre-release), 41.1.1, 40.9.0 or 39.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
39.8.940.9.242.0.0-beta.541.2.2· Vendor fix available
Issue
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
Recommended action: Upgrade to 42.0.0-beta.5 (pre-release), 41.2.2, 40.9.2 or 39.8.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.