Electron Security Vulnerabilities

Electron's nodeIntegrationInWorker webPreference fails to properly isolate Node.js integration in worker contexts across certain process-sharing configurations, allowing workers in frames explicitly configured with nodeIntegrationInWorker: false to unexpectedly gain Node.js capabilities. Only applications that explicitly enable nodeIntegrationInWorker are affected. The vulnerability carries a CVSS score of 6.8 and permits information disclosure and code execution in affected contexts, with no public exploit identified at time of analysis.

Command line injection in Electron via undocumented commandLineSwitches webPreference enables sandbox escape and security control bypass when applications spread untrusted configuration objects into webPreferences. Attackers can inject arbitrary command-line switches to disable renderer process sandboxing or web security protections, achieving local code execution with elevated privileges. CVSS 7.8 (High) with attack complexity HIGH requiring user interaction. No public exploit identified at time of analysis, though technical disclosure is public via GitHub advisory.

Electron's setLoginItemSettings() function on Windows fails to quote executable paths in the Run registry key, allowing local attackers with write access to ancestor directories to execute arbitrary programs at login if the app is installed to a path containing spaces. The vulnerability affects Electron versions prior to 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8, and requires high-privilege access and unfavorable conditions (non-standard install paths) to exploit, making real-world impact limited to non-default Windows configurations.

Electron's moveToApplicationsFolder() API on macOS improperly sanitizes application bundle paths in AppleScript fallback code, allowing arbitrary AppleScript execution when a user accepts a move-to-Applications prompt on a system with a crafted path. Remote code execution is possible if an attacker can control the installation path or launch context of an Electron application; however, this requires user interaction (accepting the move prompt) and is limited to local attack surface. No public exploit code or active exploitation has been identified. CVSS 6.5 reflects moderate risk due to local-only attack vector and user interaction requirement, though the impact (code execution) is severe.

Electron's setAsDefaultProtocolClient() on Windows fails to validate protocol names before writing to the Windows registry, allowing local authenticated attackers to hijack protocol handlers by writing to arbitrary HKCU\Software\Classes\ subkeys when apps pass untrusted input as the protocol parameter. The vulnerability affects Electron versions prior to 38.8.6, 39.8.1, 40.8.1, and 41.0.0, and requires local access and low privileges; no public exploit has been identified at time of analysis.

Electron's service worker implementation allows spoofing of internal IPC reply messages, enabling a malicious service worker to inject attacker-controlled data into the main process's promise resolution from webContents.executeJavaScript() and related methods. This affects Electron versions prior to 41.0.0, 40.8.1, 39.8.1, and 38.8.6, and impacts only applications that register service workers and rely on executeJavaScript() return values for security decisions. The vulnerability requires local authenticated access and medium attack complexity, with no public exploit code or active exploitation confirmed at analysis time.

HTTP response header injection in Electron allows remote attackers to inject malicious headers via crafted input reflected in response headers when custom protocol handlers or webRequest.onHeadersReceived are used. An attacker can manipulate cookies, content security policy, or cross-origin access controls in affected applications. This affects Electron 41.x before 41.0.3, 40.x before 40.8.3, 39.x before 39.8.3, and 38.x before 38.8.6; no public exploit code is documented at time of analysis.

Context isolation bypass in Electron applications enables privilege escalation when VideoFrame objects are bridged to the main world. Attackers with XSS capabilities can leverage improperly bridged WebCodecs API VideoFrame objects to escape the isolated context and access Node.js APIs exposed in preload scripts. CVSS 8.4 (High) with network attack vector requiring high complexity and user interaction. No public exploit identified at time of analysis, though proof-of-concept development is feasible given the detailed vendor disclosure.

Electron's WebUSB device selection handler fails to validate chosen device IDs against renderer-requested filters, allowing authenticated local users with UI interaction to bypass intended device access restrictions and gain access to unfiltered USB devices. The vulnerability affects Electron versions prior to 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, with CVSS 3.3 (low severity) due to local-only attack vector and UI interaction requirement; the WebUSB security blocklist remains enforced, limiting practical impact to applications with non-standard device selection logic.

Electron versions prior to 38.8.6, 39.8.1, 40.8.1, and 41.0.0 pass the top-level page origin instead of the requesting iframe's origin to permission request handlers for fullscreen, pointerLock, keyboardLock, openExternal, and media permissions, allowing attackers to trick applications into granting sensitive permissions to embedded third-party content via social engineering or malicious iframe injection. Unauthenticated remote attackers can exploit this via user interaction (iframe load), with CVSS 5.4 indicating moderate confidentiality and integrity impact; no public exploit code or active exploitation confirmed at time of analysis.

Out-of-bounds heap read in Electron's single-instance lock mechanism on macOS and Linux allows local attackers with same-user privileges to leak sensitive application memory through crafted second-instance messages. Affected Electron versions prior to 41.0.0, 40.8.1, 39.8.1, and 38.8.6 are vulnerable only if applications explicitly call app.requestSingleInstanceLock(); no public exploit code is currently identified, but the CVSS 5.3 score reflects moderate confidentiality impact combined with local attack complexity requirements.