Package Instance

Improper Control of Generation of Code ('Code Injection')
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.

Improper Check for Unusual or Exceptional Conditions
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`.

Trust Boundary Violation
In Electron, 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.

ASAR Integrity bypass via filetype confusion in electron
This only impacts apps that have the `embeddedAsarIntegrityValidation` and `onlyLoadAppFromAsar` [fuses](https://www.electronjs.org/docs/latest/tutorial/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.

Compromised child renderer processes could obtain IPC access without nodeIntegrationInSubFrames being enabled
### Impact
This vulnerability 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`.

Please note the misleadingly named `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access rather it depends on the existing `sandbox` setting.  If your application is sandboxed then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs (which includes `ipcRenderer`).

If your 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.

### Patches
This has been patched and the following Electron versions contain the fix:

* `18.0.0-beta.6`
* `17.2.0`
* `16.2.6`
* `15.5.5`

### Workarounds
Ensure that all IPC message handlers appropriately validate `senderFrame` as per our [security tutorial here](https://github.com/electron/electron/blob/main/docs/tutorial/security.md#17-validate-the-sender-of-all-ipc-messages).

### For more information

If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).