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
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
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
Impact A service worker running in a session could spoof reply messages on the internal IPC channel used by webContents.executeJavaScript() and related methods, causing the main-process promise to resolve with attacker-controlled data.
Apps are only affected if they have service workers registered and use the result of webContents.executeJavaScript() (or webFrameMain.executeJavaScript()) in security-sensitive decisions.
Workarounds Do not trust the return value of webContents.executeJavaScript() for security decisions. Use dedicated, validated IPC channels for security-relevant communication with renderers.
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
Impact When an iframe requests fullscreen, pointerLock, keyboardLock, openExternal, or media permissions, the origin passed to session.setPermissionRequestHandler() was the top-level page's origin rather than the requesting iframe's origin. Apps that grant permissions based on the origin parameter or webContents.getURL() may inadvertently grant permissions to embedded third-party content.
The correct requesting URL remains available via details.requestingUrl. Apps that already check details.requestingUrl are not affected.
Workarounds In your setPermissionRequestHandler, inspect details.requestingUrl rather than the origin parameter or webContents.getURL() when deciding whether to grant fullscreen, pointerLock, keyboardLock, openExternal, or media permissions.
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
Impact On macOS and Linux, apps that call app.requestSingleInstanceLock() were vulnerable to an out-of-bounds heap read when parsing a crafted second-instance message. Leaked memory could be delivered to the app's second-instance event handler.
This issue is limited to processes running as the same user as the Electron app.
Apps that do not call app.requestSingleInstanceLock() are not affected. Windows is not affected by this issue.
Workarounds There are no app side workarounds, developers must update to a patched version of Electron.
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