In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. Apps using both contextIsolation and contextBridge are affected. This is fixed in versions 9.0.0-beta.21, 8.2.4 and 7.2.4.

Impact 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 and contextIsolation disabled. i.e. sandbox: false and contextIsolation: false in the webPreferences object.

This resulted in incorrectly allowing usage of methods like eval() and new Function, which can result in an expanded attack surface.

Patches 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 - 23.0.0-alpha.2

We recommend all apps upgrade to the latest stable version of Electron, especially if they use sandbox: false or contextIsolation: false.

Workarounds If upgrading isn't possible, this issue can be addressed without upgrading by enabling at least one of sandbox: true or contextIsolation: true on all renderers.

js const mainWindow = new BrowserWindow({ webPreferences: { sandbox: true, } });

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org.

Credit Thanks to user @andreasdj for reporting this issue.

Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. A vulnerability in versions prior to 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 allows a renderer with JS execution to obtain access to a new renderer process with nodeIntegrationInSubFrames enabled which in turn allows effective access to ipcRenderer. The nodeIntegrationInSubFrames option does not implicitly grant Node.js access. Rather, it depends on the existing sandbox setting. If an application is sandboxed, then nodeIntegrationInSubFrames just gives access to the sandboxed renderer APIs, which include ipcRenderer. If the application then additionally exposes IPC messages without IPC senderFrame validation that perform privileged actions or return confidential data this access to ipcRenderer can in turn compromise your application / user even with the sandbox enabled. Electron versions 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 contain a fix for this issue. As a workaround, ensure that all IPC message handlers appropriately validate senderFrame.

Github Electron version Electron 1.8.2-beta.4 and earlier contains a Command Injection vulnerability in Protocol Handler that can result in command execute. This attack appear to be exploitable via the victim opening an electron protocol handler in their browser. This vulnerability appears to have been fixed in Electron 1.8.2-beta.5. This issue is due to an incomplete fix for CVE-2018-1000006, specifically the black list used was not case insensitive allowing an attacker to potentially bypass it.

zonote through 0.4.0 allows XSS via a crafted note, with resultant Remote Code Execution (because nodeIntegration in webPreferences is true).

In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. Apps using contextIsolation are affected. This is fixed in versions 9.0.0-beta.21, 8.2.4 and 7.2.4.

Poddycast is a podcast app made with Electron. Prior to version 0.8.1, an attacker can create a podcast or episode with malicious characters and execute commands on the client machine. The application does not clean the HTML characters of the podcast information obtained from the Feed, which allows the injection of HTML and JS code (cross-site scripting). Being an application made in electron, cross-site scripting can be scaled to remote code execution, making it possible to execute commands on the machine where the application is running. The vulnerability is patched in Poddycast version 0.8.1.

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

Workarounds This issue is exploitable under either of two conditions: If an API exposed to the main world via contextBridge can return an object or array that contains a JS 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. If an API exposed to the main world via contextBridge has a return value that throws a user-generated exception while being sent over the bridge, for instance a dynamic getter property on an object that throws an error when being computed.

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 and that any objects returned from functions do not have dynamic getters that can throw exceptions.

Auditing your exposed API is likely to be quite difficult so we strongly recommend you update to a patched version of Electron.

Fixed Versions 25.0.0-alpha.2 24.0.1 23.2.3 22.3.6

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

A vulnerability has been discovered which allows Node.js integration to be re-enabled in some Electron applications that disable it.

For the application to be impacted by this vulnerability it must meet all of these conditions

- Runs on Electron 1.7, 1.8, or a 2.0.0-beta - Allows execution of arbitrary remote code - Disables Node.js integration - Does not explicitly declare webviewTag: false in its webPreferences - Does not enable the nativeWindowOption option - Does not intercept new-window events and manually override event.newGuest without using the supplied options tag

Recommendation

Update to electron version 1.7.13, 1.8.4, or 2.0.0-beta.5 or later.

If you are unable to update your Electron version can mitigate the vulnerability with the following code.

js app.on('web-contents-created', (event, win) => { win.on('new-window', (event, newURL, frameName, disposition, options, additionalFeatures) => { if (!options.webPreferences) options.webPreferences = {}; options.webPreferences.nodeIntegration = false; options.webPreferences.nodeIntegrationInWorker = false; options.webPreferences.webviewTag = false; delete options.webPreferences.preload; }) })

// and IF you don't use WebViews at all, // you might also want app.on('web-contents-created', (event, win) => { win.on('will-attach-webview', (event, webPreferences, params) => { event.preventDefault(); }) })

GitHub Electron 1.7.15, 1.8.7, 2.0.7, and 3.0.0-beta.6, in certain scenarios involving IFRAME elements and "nativeWindowOpen: true" or "sandbox: true" options, is affected by a WebPreferences vulnerability that can be leveraged to perform remote code execution.

Observations The file packages/electron-updater/src/windowsExecutableCodeSignatureVerifier.ts implements the signature validation routine for Electron applications on Windows. It executes the following command in a new shell (process.env.ComSpec on Windows, usually C:\Windows\System32\cmd.exe):

https://github.com/electron-userland/electron-builder/blob/140e2f0eb0df79c2a46e35024e96d0563355fc89/packages/electron-updater/src/windowsExecutableCodeSignatureVerifier.ts#L35-L41

Because of the surrounding shell, a first pass by cmd.exe expands any environment variable found in command-line above.

Exploitation

This creates a situation where verifySignature() can be tricked into validating the certificate of a different file than the one that was just downloaded. If the step is successful, the malicious update will be executed even if its signature is invalid.

Impact

This attack assumes a compromised update manifest (server compromise, Man-in-the-Middle attack if fetched over HTTP, Cross-Site Scripting to point the application to a malicious updater server, etc.).

Patch

This vulnerability was patched in #8295, by comparing the path in the output of Get-AuthenticodeSignature with the intended one. The patch is available starting from 6.3.0-alpha.6.

In Electron before versions 11.0.0-beta.1, 10.0.1, 9.3.0 or 8.5.1 the will-navigate event that apps use to prevent navigations to unexpected destinations as per our security recommendations can be bypassed when a sub-frame performs a top-frame navigation across sites. The issue is patched in versions 11.0.0-beta.1, 10.0.1, 9.3.0 or 8.5.1 As a workaround sandbox all your iframes using the sandbox attribute. This will prevent them creating top-frame navigations and is good practice anyway.

In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. As a workaround, ensure you are calling event.preventDefault() on all new-window events where the url or options is not something you expect. This is fixed in versions 9.0.0-beta.21, 8.2.4 and 7.2.4.

Electron is a framework for writing cross-platform desktop applications using JavaScript (JS), HTML, and CSS. A vulnerability in versions prior to 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 allows attackers who have control over a given apps update server / update storage to serve maliciously crafted update packages that pass the code signing validation check but contain malicious code in some components. This kind of attack would require significant privileges in a potential victim's own auto updating infrastructure and the ease of that attack entirely depends on the potential victim's infrastructure security. Electron versions 18.0.0-beta.6, 17.2.0, 16.2.6, and 15.5.5 contain a fix for this issue. There are no known workarounds.

The Electron framework enables writing cross-platform desktop applications using JavaScript, HTML and CSS. In versions prior to 21.0.0-beta.1, 20.0.1, 19.0.11, and 18.3.7, Electron is vulnerable to Exposure of Sensitive Information. When following a redirect, Electron delays a check for redirecting to file:// URLs from other schemes. The contents of the file is not available to the renderer following the redirect, but if the redirect target is a SMB URL such as file://some.website.com/, then in some cases, Windows will connect to that server and attempt NTLM authentication, which can include sending hashed credentials.This issue has been patched in versions: 21.0.0-beta.1, 20.0.1, 19.0.11, and 18.3.7. Users are recommended to upgrade to the latest stable version of Electron. If upgrading isn't possible, this issue can be addressed without upgrading by preventing redirects to file:// URLs in the WebContents.on('will-redirect') event, for all WebContents as a workaround.

Impact 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 resources folder in your app installation on Windows which these fuses are supposed to protect against.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 27.0.0-alpha.7 26.2.1 25.8.1 24.8.3 22.3.24

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Electron before versions 11.0.0-beta.6, 10.1.2, 9.3.1 or 8.5.2 is vulnerable to a context isolation bypass. Apps using both contextIsolation and sandbox: true are affected. Apps using both contextIsolation and nodeIntegrationInSubFrames: true 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.

In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there 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. Apps using "contextIsolation" are affected. There are no app-side workarounds, you must update your Electron version to be protected. This is fixed in versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21.

Impact Apps that are launched as command line executables are impacted. E.g. if your app exposes itself in the path as myapp --help

Specifically this issue can only be exploited if the following conditions are met: Your app is launched with an attacker-controlled working directory 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. Please bear this in mind when reporting similar issues in the future.

Workarounds There are no app side workarounds, you must update to a patched version of Electron.

Fixed Versions 26.0.0-beta.13 25.5.0 24.7.1 23.3.13 22.3.19

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org

Impact IPC messages sent from the main process to a subframe in the renderer process, through webContents.sendToFrame, event.reply or when using the remote module, can in some cases be delivered to the wrong frame.

If your app does ANY of the following, then it is impacted by this issue: - Uses remote - Calls webContents.sendToFrame - Calls event.reply in an IPC message handler

Patches This has been fixed in the following versions:

- 9.4.0 - 10.2.0 - 11.1.0 - 12.0.0-beta.9

Workarounds There are no workarounds for this issue.

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org.

Impact This vulnerability allows renderers to obtain access to a random bluetooth device via the web bluetooth API if the app has not configured a custom select-bluetooth-device event handler. The device that is accessed is random and the attacker would have no way of selecting a specific device.

All current stable versions of Electron are affected.

Patches This has been patched and the following Electron versions contain the fix: 17.0.0-alpha.6 16.0.6 15.3.5 14.2.4 13.6.6

Workarounds Adding this code to your app can workaround the issue.

js app.on('web-contents-created', (event, webContents) => { webContents.on('select-bluetooth-device', (event, devices, callback) => { // Prevent default behavior event.preventDefault(); // Cancel the request callback(''); }); });

For more information If you have any questions or comments about this advisory, email us at security@electronjs.org.

End of life: 8/20/2024, Latest version: 29.4.6

End of life: 8/20/2024, Latest version: 29.4.6

End of life: 4/16/2024, Latest version: 27.3.11

End of life: 4/16/2024, Latest version: 27.3.11

End of life: 10/15/2024, Latest version: 30.5.1

End of life: 10/15/2024, Latest version: 30.5.1

End of life: 6/11/2024, Latest version: 28.3.3

End of life: 6/11/2024, Latest version: 28.3.3

End of life: 12/5/2023, Latest version: 25.9.8