Electron vulnerabilities, page 4

66 vulnerabilities

Known vulnerabilities in Electron products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 4 products.

8.8CVE-2026-34765electronelectron+2
EPSS score
0.38%
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5, when a renderer calls window.open() with a target name, Electron did not correctly scope the named-window lookup to the opener's browsing context group. A renderer could navigate an existing child window that was opened by a different, unrelated renderer if both used the same target name. If that existing child was created with more permissive webPreferences (via setWindowOpenHandler's overrideBrowserWindowOptions), content loaded by the second renderer inherits those permissions. Apps are only affected if they open multiple top-level windows with differing trust levels and use setWindowOpenHandler to grant child windows elevated webPreferences such as a privileged preload script. Apps that do not elevate child window privileges, or that use a single top-level window, are not affected. Apps that additionally grant nodeIntegration: true or sandbox: false to child windows (contrary to the security recommendations) may be exposed to arbitrary code execution. This vulnerability is fixed in 39.8.5, 40.8.5, 41.1.0, and 42.0.0-alpha.5.5.4CVE-2026-34777electronelectron+2
EPSS score
0.13%
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.1, 40.8.1, and 41.0.0, when an iframe requests fullscreen, pointerLock, keyboardLock, openExternal, or media permissions, the origin passed to session.setPermissionRequestHandler() was the top-level page's origin rather than the requesting iframe's origin. Apps that grant permissions based on the origin parameter or webContents.getURL() may inadvertently grant permissions to embedded third-party content. The correct requesting URL remains available via details.requestingUrl. Apps that already check details.requestingUrl are not affected. This issue has been patched in versions 38.8.6, 39.8.1, 40.8.1, and 41.0.0.6.6CVE-2023-39956electronelectron+2
EPSS score
0.49%
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Electron apps that are launched as command line executables are impacted. Specifically this issue can only be exploited if the following conditions are met: 1. The app is launched with an attacker-controlled working directory and 2. The attacker has the ability to write files to that working directory. This makes the risk quite low, in fact normally issues of this kind are considered outside of our threat model as similar to Chromium we exclude Physically Local Attacks but given the ability for this issue to bypass certain protections like ASAR Integrity it is being treated with higher importance. This issue has been fixed in versions:`26.0.0-beta.13`, `25.4.1`, `24.7.1`, `23.3.13`, and `22.3.19`. There are no app side workarounds, users must update to a patched version of Electron.8.5CVE-2023-29198electronelectron+2
EPSS score
0.59%
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. Electron apps using `contextIsolation` and `contextBridge` are affected. This is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. This issue is only exploitable if an API exposed to the main world via `contextBridge` can return an object or array that contains a javascript object which cannot be serialized, for instance, a canvas rendering context. This would normally result in an exception being thrown `Error: object could not be cloned`. The app side workaround is to ensure that such a case is not possible. Ensure all values returned from a function exposed over the context bridge are supported. This issue has been fixed in versions `25.0.0-alpha.2`, `24.0.1`, `23.2.3`, and `22.3.6`.7CVE-2023-44402electronelectron+2
EPSS score
0.21%
Electron is an open source framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` fuses enabled. Apps without these fuses enabled are not impacted. This issue is specific to macOS as these fuses are only currently supported on macOS. Specifically this issue can only be exploited if your app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the `.app` bundle on macOS which these fuses are supposed to protect against. There are no app side workarounds, you must update to a patched version of Electron.9.8CVE-2023-23623electronelectron+2
EPSS score
0.66%
Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox disabled. i.e. `sandbox: false` in the `webPreferences` object. This allows usage of methods like `eval()` and `new Function` unexpectedly which can result in an expanded attack surface. This issue only ever affected the 22 and 23 major versions of Electron and has been fixed in the latest versions of those release lines. Specifically, these versions contain the fixes: 22.0.1 and 23.0.0-alpha.2 We recommend all apps upgrade to the latest stable version of Electron. If upgrading isn't possible, this issue can be addressed without upgrading by enabling `sandbox: true` on all renderers.