CVE-2026-114124

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 42.11.16, 43.8.1, 44.9.1, and 45.0.0-beta.6, Electron does not block compromised eMudhra intermediate certificates in Chromium networking, Node.js tls, Node.js https, or Node.js fetch. An attacker who holds a certificate issued through one of these intermediates and can intercept network traffic can impersonate a TLS server to an affected application.

In Electron prior to versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9, frame data received from the GPU process for webContents.beginFrameSubscription was not fully validated by the main process. An attacker with code execution in the GPU process could supply inconsistent frame geometry and cause the main process to read out-of-bounds memory, disclosing memory or crashing the application.

In Electron prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, requests to open external protocol URLs could be attributed to a document other than the one that initiated them. This caused the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content.

Electron is a framework for writing cross-platform desktop applications. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, hid and usb permission checks made from an iframe caused setPermissionCheckHandler to receive the top-level frame's origin and details instead of the requesting frame's. An application that delegated hid or usb to a cross-origin untrusted iframe and allowed device access with origin-based logic could therefore grant that embedded frame access intended for the top-level page.

In the Electron framework, pointerLock permission requests from some cross-origin iframes caused session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of those of the requesting frame. An application embedding untrusted iframe content and granting pointer lock based on the requesting origin could grant the permission under the top-level page's identity. This is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.

In the Electron framework, chrome.tabs.query() returned each tab's URL and title to extensions that lacked both the tabs permission and matching host permissions. An application loading an untrusted extension via session.extensions.loadExtension could allow it to read the URL and title of every webContents in its session. This is fixed in versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4.

In Electron prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6, pages opened into a new window from links were treated as application-initiated navigations instead of preserving the page containing the link as the initiator. The resulting top-level request could be classified as same-site, causing SameSite=Strict cookies to be sent and Sec-Fetch-Site not to identify the initiating page.

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.