Electronjs Electron 9.0.0 Beta22

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.

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.

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

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.

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.

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

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. A vulnerability in versions prior to `17.0.0-alpha.6`, `16.0.6`, `15.3.5`, `14.2.4`, and `13.6.6` allows renderers to obtain access to a bluetooth device via the web bluetooth API if the app has not configured a custom `select-bluetooth-device` event handler. This has been patched and Electron versions `17.0.0-alpha.6`, `16.0.6`, `15.3.5`, `14.2.4`, and `13.6.6` contain the fix. Code from the GitHub Security Advisory can be added to the app to work around the issue.

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.

The Electron framework lets you write cross-platform desktop applications using JavaScript, HTML and CSS. In affected versions of Electron 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 uses remote, calls webContents.sendToFrame, or calls event.reply in an IPC message handler then it is impacted by this issue. This has been fixed in versions 9.4.0, 10.2.0, 11.1.0, and 12.0.0-beta.9. There are no workarounds for this issue.

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.