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.

Impact The nodeIntegrationInWorker webPreference was not correctly scoped in all configurations. In certain process-sharing scenarios, workers spawned in frames configured with nodeIntegrationInWorker: false could still receive Node.js integration.

Apps are only affected if they enable nodeIntegrationInWorker. Apps that do not use nodeIntegrationInWorker are not affected.

Workarounds Avoid enabling nodeIntegrationInWorker in apps that also open child windows or embed content with differing webPreferences.

Fixed Versions 41.0.0 40.8.4 39.8.4 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Affected versions of ElectronJS are susceptible to a remote code execution vulnerability that occurs when an affected application access remote content, even if the sandbox option is enabled.

Recommendation

Update to electron version 1.7.8 or later.

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.

Impact Apps that use the powerMonitor module may be vulnerable to a use-after-free. After the native PowerMonitor object is garbage-collected, the associated OS-level resources (a message window on Windows, a shutdown handler on macOS) retain dangling references. A subsequent session-change event (Windows) or system shutdown (macOS) dereferences freed memory, which may lead to a crash or memory corruption.

All apps that access powerMonitor events (suspend, resume, lock-screen, etc.) are potentially affected. The issue is not directly renderer-controllable.

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

Fixed Versions 41.0.0-beta.8 40.8.0 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact Apps that register an asynchronous session.setPermissionRequestHandler() may be vulnerable to a use-after-free when handling fullscreen, pointer-lock, or keyboard-lock permission requests. If the requesting frame navigates or the window closes while the permission handler is pending, invoking the stored callback dereferences freed memory, which may lead to a crash or memory corruption.

Apps that do not set a permission request handler, or whose handler responds synchronously, are not affected.

Workarounds Respond to permission requests synchronously, or deny fullscreen, pointer-lock, and keyboard-lock requests if an asynchronous flow is required.

Fixed Versions 41.0.0-beta.8 40.7.0 39.8.0 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact An undocumented commandLineSwitches webPreference allowed arbitrary switches to be appended to the renderer process command line. Apps that construct webPreferences by spreading untrusted configuration objects may inadvertently allow an attacker to inject switches that disable renderer sandboxing or web security controls.

Apps are only affected if they construct webPreferences from external or untrusted input without an allowlist. Apps that use a fixed, hardcoded webPreferences object are not affected.

Workarounds Do not spread untrusted input into webPreferences. Use an explicit allowlist of permitted preference keys when constructing BrowserWindow or webContents options from external configuration.

Fixed Versions 41.0.0-beta.8 40.7.0 39.8.0 38.8.6

For more information If there are any questions or comments about this advisory, send an email to security@electronjs.org

Impact Apps that allow downloads and programmatically destroy sessions may be vulnerable to a use-after-free. If a session is torn down while a native save-file dialog is open for a download, dismissing the dialog dereferences freed memory, which may lead to a crash or memory corruption.

Apps that do not destroy sessions at runtime, or that do not permit downloads, are not affected.

Workarounds Avoid destroying sessions while a download save dialog may be open. Cancel pending downloads before session teardown.

Fixed Versions 41.0.0-beta.7 40.7.0 39.8.0 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

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

Workarounds Deny window.open() in renderers that load untrusted content by returning { action: 'deny' } from setWindowOpenHandler. Avoid granting child windows more permissive webPreferences than their opener.

Fixed Versions 42.0.0-alpha.5 41.1.0 40.8.5 39.8.5

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

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.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. A vulnerability in versions prior to 11.5.0, 12.1.0, and 13.3.0 allows a sandboxed renderer to request a "thumbnail" image of an arbitrary file on the user's system. The thumbnail can potentially include significant parts of the original file, including textual data in many cases. Versions 15.0.0-alpha.10, 14.0.0, 13.3.0, 12.1.0, and 11.5.0 all contain a fix for the vulnerability. Two workarounds aside from upgrading are available. One may make the vulnerability significantly more difficult for an attacker to exploit by enabling contextIsolation in one's app. One may also disable the functionality of the createThumbnailFromPath API if one does not need it.

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

Impact Apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script.

Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected.

Workarounds Do not pass VideoFrame objects across contextBridge. If an app needs to transfer video frame data, serialize it to an ArrayBuffer or ImageBitmap before bridging.

Fixed Versions 41.0.0-beta.8 40.7.0 39.8.0

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact Apps that use offscreen rendering and allow child windows via window.open() may be vulnerable to a use-after-free. If the parent offscreen WebContents is destroyed while a child window remains open, subsequent paint frames on the child dereference freed memory, which may lead to a crash or memory corruption.

Apps are only affected if they use offscreen rendering (webPreferences.offscreen: true) and their setWindowOpenHandler permits child windows. Apps that do not use offscreen rendering, or that deny child windows, are not affected.

Workarounds Deny child window creation from offscreen renderers in your setWindowOpenHandler, or ensure child windows are closed before the parent is destroyed.

Fixed Versions 41.0.0 40.7.0 39.8.1

For more information If there are any questions or comments about this advisory, please email 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.

Impact On macOS, app.moveToApplicationsFolder() used an AppleScript fallback path that did not properly handle certain characters in the application bundle path. Under specific conditions, a crafted launch path could lead to arbitrary AppleScript execution when the user accepted the move-to-Applications prompt.

Apps are only affected if they call app.moveToApplicationsFolder(). Apps that do not use this API are not affected.

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

Fixed Versions 41.0.0-beta.8 40.8.0 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

Impact On Windows, app.setLoginItemSettings({openAtLogin: true}) wrote the executable path to the Run registry key without quoting. If the app is installed to a path containing spaces, an attacker with write access to an ancestor directory may be able to cause a different executable to run at login instead of the intended app.

On a default Windows install, standard system directories are protected against writes by standard users, so exploitation typically requires a non-standard install location.

Workarounds Install the application to a path without spaces, or to a location where all ancestor directories are protected against unauthorized writes.

Fixed Versions 41.0.0-beta.8 40.8.0 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, send an email to security@electronjs.org

Impact On Windows, app.setAsDefaultProtocolClient(protocol) did not validate the protocol name before writing to the registry. Apps that pass untrusted input as the protocol name may allow an attacker to write to arbitrary subkeys under HKCU\Software\Classes\, potentially hijacking existing protocol handlers.

Apps are only affected if they call app.setAsDefaultProtocolClient() with a protocol name derived from external or untrusted input. Apps that use a hardcoded protocol name are not affected.

Workarounds Validate the protocol name matches /^[a-zA-Z][a-zA-Z0-9+.-]$/ before passing it to app.setAsDefaultProtocolClient().

Fixed Versions 41.0.0 40.8.1 39.8.1 38.8.6

For more information If there are any questions or comments about this advisory, please email security@electronjs.org

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.