EUVD-2026-53462
GHSA-v93f-fgjr-hjrj
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Network-delivered renderer content requires no auth; impact limited to main process accessing attacker-chosen paths, yielding partial confidentiality loss with no integrity or availability impact.
Primary rating from Vendor (https://github.com/electron/electron).
CVSS VectorVendor: https://github.com/electron/electron
Lifecycle Timeline
3DescriptionCVE.org
Impact
Some window options supplied by web content in the window.open() features string were applied to the new BrowserWindow without an allowlist. Untrusted content could set window options it should not control, including options that cause the main process to access attacker-chosen file or network paths.
Apps are only affected if untrusted content can call window.open() and the app does not override child window options via setWindowOpenHandler. Apps that deny window.open() for untrusted content, or set overrideBrowserWindowOptions explicitly, are not affected.
Workarounds
Return { action: 'deny' } from setWindowOpenHandler for untrusted content, or supply overrideBrowserWindowOptions so every window option is set explicitly.
Fixed Versions
42.0.0-beta.341.2.140.9.039.8.8
For more information
If you have any questions or comments about this advisory, email Electron at [security@electronjs.org](mailto:security@electronjs.org)
AnalysisAI
Electron's window.open() features string parsing forwards untrusted BrowserWindowConstructorOptions directly to child BrowserWindows without an allowlist, allowing renderer-side web content to supply privileged options - such as icon - that cause the trusted main process to access attacker-chosen file or network paths. All Electron apps serving untrusted web content without a setWindowOpenHandler guard are affected across the 39.x, 40.x, 41.x, and 42.x beta series. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog; the practical attack surface is narrowed to apps that load third-party or user-controlled content and omit the recommended setWindowOpenHandler override.
Technical ContextAI
Electron (pkg:npm/electron) wraps Chromium and Node.js to build cross-platform desktop applications, with a split trust model: the renderer process handles web content and is considered untrusted, while the main process holds privileged OS access. Child windows spawned via window.open() accept a comma-separated features string that Electron's parseFeatures() function in lib/browser/parse-features-string.ts parsed into BrowserWindowConstructorOptions and forwarded verbatim to the new BrowserWindow constructor. Because BrowserWindowConstructorOptions includes options like icon that trigger main-process filesystem or network I/O, a malicious renderer could inject these into the features string, bypassing the renderer/main process trust boundary. The root cause is CWE-20 (Improper Input Validation): the absence of an allowlist meant all parsed options from untrusted renderer content reached a privileged API surface. The fix introduces a hardcoded allowedWindowOptions Set in parse-features-string.ts that permits only presentational options (width, height, title, backgroundColor, frame, etc.) and silently drops any option with filesystem or network side effects.
RemediationAI
Upgrade Electron to a patched release: 39.8.8, 40.9.0, 41.2.1, or 42.0.0-beta.3, available at the respective GitHub release pages (e.g., https://github.com/electron/electron/releases/tag/v41.2.1 for the 41.x line). If an immediate upgrade is not feasible, implement setWindowOpenHandler in the main process and return { action: 'deny' } for any window.open() call originating from untrusted content - this blocks the vulnerable code path entirely but will prevent any child windows from opening, which may break app functionality. Where child windows are required, instead supply overrideBrowserWindowOptions within the setWindowOpenHandler return value to explicitly set every relevant BrowserWindow option, ensuring renderer-supplied values are overwritten and cannot influence privileged parameters. The overrideBrowserWindowOptions approach preserves functionality while eliminating the attack path, making it the preferred workaround over blanket denial.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today