Vulnerability feed

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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 macOS offscreen rendering was not fully validated by the main process. An attacker who had separately gained code execution in the GPU process could provide inconsistent frame geometry and cause the main process to read out-of-bounds memory while producing paint event images, disclosing memory or crashing the application. This issue is fixed in versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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 who had separately gained code execution in the GPU process could supply inconsistent frame geometry and cause the main process to read out-of-bounds memory while producing captured frame images, disclosing memory or crashing the application. This issue is fixed in versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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, causing the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content. An application that grants openExternal based on the requesting origin and allows untrusted content to open or navigate windows could therefore allow that content to launch an OS-registered external application. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13, 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 that embeds untrusted iframe content and grants pointer lock based on the requesting origin could therefore grant the permission under the top-level page's identity. Applications that deny pointerLock for untrusted embedded content are not affected. This issue is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4, chrome.tabs.query() returned each tab's url and title to extensions that had neither the tabs permission nor matching host permissions. An application that loaded an extension it did not fully trust through session.extensions.loadExtension could therefore allow that extension to read the URL and title of every webContents in its session. This issue is fixed in versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6, Electron treated pages opened into a new window from links 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. An application that loads untrusted content and permits it to open new windows could therefore allow that content to make a credentialed request to another site that relies on SameSite cookies for CSRF protection. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.10, 41.10.5, and 42.0.0-beta.2, Electron applications on macOS that use Squirrel.Mac-based automatic updates are vulnerable to a local race in the privileged ShipIt helper. The helper did not bind the validated update target to one canonical application-bundle path for the full installation, allowing a local attacker to redirect the root-level write so that it overwrites another application's files instead of the application that initiated the update. Applications on other platforms and macOS applications that do not use Squirrel.Mac-based automatic updates are not affected. This issue is fixed in versions 39.8.10, 41.10.5, and 42.0.0-beta.2.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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 writing cross-platform desktop applications using JavaScript, HTML and CSS. 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, allowing untrusted guest content to create a Node-enabled worker with more privilege than the embedder granted. Applications that do not enable the <webview> tag or that keep the embedder sandboxed are not affected. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme registered with supportFetchAPI enabled but corsEnabled disabled could remain script-readable across origins. This residual issue completes the remediation for CVE-2026-70604. Applications are affected only when they expose such a scheme and load untrusted content in the same session. Schemes intentionally registered with corsEnabled enabled remain cross-origin readable by design. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, windows opened from a sandboxed top-level document did not inherit that document's active HTML sandbox restrictions. Untrusted content in a sandboxed top-level document that was permitted to open popups could therefore create a window with the Electron application's full origin instead of the restricted origin intended by the sandbox. Applications that deny such popups with setWindowOpenHandler are not affected. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.4, 42.5.2, and 43.0.0, popups opened from a sandboxed iframe through Electron's OpenURLFromTab navigation path, including links using target="_blank" or a middle-click, did not receive the inherited HTML sandbox restrictions. An untrusted iframe using the allow-scripts allow-popups configuration could therefore open a popup with the embedding application's full origin, exposing that origin's cookies, storage, and same-origin scripting capabilities. Applications that do not embed untrusted content in sandboxed iframes are not affected. This issue is fixed in versions 41.10.4, 42.5.2, and 43.0.0.