electron

### 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 miti

CVE: CVE-2026-115570

### 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 `setWindowOpenHand

CVE: CVE-2026-113796

### 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 versi

CVE: CVE-2026-114122

### 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` *

CVE: CVE-2026-113797

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

CVE: CVE-2026-114121

### 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. ### Wor

CVE: CVE-2026-114124

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

CVE: CVE-2026-113798

### 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="hi

CVE: CVE-2026-113800

### 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`

CVE: CVE-2026-102676

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

CVE: CVE-2026-102674