End of life: 6/24/2025, Latest version: 34.5.8
End of life: 1/14/2025, Latest version: 31.7.7
End of life: 1/14/2025, Latest version: 31.7.7
End of life: 3/4/2025, Latest version: 32.3.3
End of life: 3/4/2025, Latest version: 32.3.3
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: 8/20/2024, Latest version: 29.4.6
End of life: 8/20/2024, Latest version: 29.4.6
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.
End of life: 6/11/2024, Latest version: 28.3.3
End of life: 6/11/2024, Latest version: 28.3.3
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
End of life: 4/16/2024, Latest version: 27.3.11
End of life: 4/16/2024, Latest version: 27.3.11
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 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 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.
End of life: 2/20/2024, Latest version: 26.6.10
End of life: 2/20/2024, Latest version: 26.6.10
End of life: 12/5/2023, Latest version: 25.9.8
End of life: 12/5/2023, Latest version: 25.9.8
End of life: 10/10/2023, Latest version: 24.8.8
End of life: 10/10/2023, Latest version: 24.8.8
End of life: 8/15/2023, Latest version: 23.3.13
End of life: 8/15/2023, Latest version: 23.3.13
End of life: 10/10/2023, Latest version: 22.3.27
End of life: 10/10/2023, Latest version: 22.3.27
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.
End of life: 4/4/2023, Latest version: 21.4.4