Advisories for Npm/Electron package

Most apps will crash and some may perform incorrect buffer allocations in the Node.js Buffer API resulting in unexpected truncation or allocation.

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 …

Apps that call clipboard.readImage() may be vulnerable to a denial of service. If the system clipboard contains image data that fails to decode, the resulting null bitmap is passed unchecked to image construction, triggering a controlled abort and crashing the process. Apps are only affected if they call clipboard.readImage(). Apps that do not read images from the clipboard are not affected. This issue does not allow memory corruption or code …

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.

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

Apps that use offscreen rendering with GPU shared textures may be vulnerable to a use-after-free. Under certain conditions, the release() callback provided on a paint event texture can outlive its backing native state, and invoking it after that point dereferences freed memory in the main process, which may lead to a crash or memory corruption. Apps are only affected if they use offscreen rendering with webPreferences.offscreen: { useSharedTexture: true }. …

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 …

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.

The select-usb-device event callback did not validate the chosen device ID against the filtered list that was presented to the handler. An app whose handler could be influenced to select a device ID outside the filtered set would grant access to a device that did not match the renderer's requested filters or was listed in exclusionFilters. The WebUSB security blocklist remained enforced regardless, so security-sensitive devices on the blocklist were …

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

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.

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.

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.

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.

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.

Apps that register custom protocol handlers via protocol.handle() / protocol.registerSchemesAsPrivileged() or modify response headers via webRequest.onHeadersReceived may be vulnerable to HTTP response header injection if attacker-controlled input is reflected into a response header name or value. An attacker who can influence a header value may be able to inject additional response headers, affecting cookies, content security policy, or cross-origin access controls. Apps that do not reflect external input into response …

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 …

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.

This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted. 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.

The nativeImage.createFromPath() and nativeImage.createFromBuffer() functions call a function downstream that is vulnerable to a heap buffer overflow. An Electron program that uses either of the affected functions is vulnerable to a buffer overflow if an attacker is in control of the image's height, width, and contents.

electron's ASAR Integrity can be bypass by modifying the content.

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 …

Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Heap buffer overflow in libwebp allow a remote attacker to perform an out of bounds memory write via a crafted HTML page.

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, …

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 …

Electron is a framework which lets you write cross-platform desktop applications using JavaScript, HTML and CSS. 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 disabled. i.e. sandbox: false in the webPreferences object. This allows usage of methods like eval() and new Function unexpectedly which can result in an expanded attack surface. This issue …

Heap buffer overflow in GPU in Google Chrome prior to 107.0.5304.121 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

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 …

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 …

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 …

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 …

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. A vulnerability 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. all contain a fix for the vulnerability. Two workarounds aside from upgrading are available. One may make the vulnerability significantly …

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 does ANY of the following, then it is impacted by this issue: Uses remote Calls webContents.sendToFrame Calls event.reply in an IPC message handler

In Electron 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 As a workaround sandbox all your iframes using the sandbox attribute. This will prevent them creating top-frame navigations and is good practice anyway.

Electron 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, 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.

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

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

In Electron, an 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.

GitHub Electron is affected by a WebPreferences vulnerability that can be leveraged to perform remote code execution.

A remote code execution vulnerability has been discovered in Google Chromium that affects all recent versions of Electron.

Electron contains an improper handling of values vulnerability in Webviews that can result in remote code execution. .

Github Electron version Electron contains a Command Injection vulnerability in Protocol Handler that can result in command execute.This issue is due to an incomplete fix for CVE-2018-1000006, specifically the block list used was not case insensitive allowing an attacker to potentially bypass it.

GitHub Electron has a vulnerability in the protocol handler.

Github Electron is vulnerable to a URL Spoofing problem when opening PDFs in PDFium resulting loading arbitrary PDFs that a hacker can control.

Untrusted search path vulnerability in Atom Electron before 0.33.5 allows local users to gain privileges via a Trojan horse Node.js module in a parent directory of a directory named on a require line.

A remote code execution vulnerability has been discovered in Google Chromium that affects all recent versions of Electron. Any Electron app that accesses remote content is vulnerable to this exploit, regardless of whether the sandbox option is enabled.

Recent Electron versions do not have strict Same Origin Policy (SOP) enforcement. Combining an SOP bypass with a privileged URL internally used by Electron, it was possible to execute native Node.js primitives in order to run OS commands on the user's host.