Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAttacker controls content loaded in Electron webview
-
DeliveryWebview content invokes openDevTools with injected mode string
-
ExploitUnsanitized string reaches DevTools frontend JavaScript context
-
ExecutionInjected payload executes in DevTools context
-
PersistNode.js APIs accessed in unsandboxed Electron process
-
ImpactArbitrary OS-level commands executed on host system
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Code injection prevention, sandbox exec
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Two concurrent conditions must both be satisfied: (1) the Electron application must be configured without the renderer sandbox, meaning the DevTools context retains Node.js API access (this is non-default in modern Electron but common in legacy apps using nodeIntegration or contextIsolation:false); AND (2) either untrusted external input must reach the |
| Impact | The official CVSS 3.1 score is 5.7 (Medium) with vector AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N. The PR:H and S:U choices appear to model the scenario where the developer's own application code is the only pathway for untrusted input to reach |
| Exploit ScenarioDerived | An attacker who controls web content loaded inside an Electron |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 05, 2026
Code injection in Electron's DevTools API permits arbitrary script execution in the DevTools context via an unsanitized mode parameter supplied to webContents.openDevTools(). Unsandboxed Electron applications where untrusted input reaches the mode argument - or where untrusted content embedded in a <webview> element can invoke openDevTools() - are exposed to full Node.js-level code execution on the host operating system. No public exploit has been identified at time of analysis, but Electron's own GitHub Security Advisory (GHSA-4f78-qhmw-8j8m) confirms the flaw and vendor-released patches are available across all active release tracks.
RemediationAI
Upgrade Electron to a fixed version matching your active release track: 39.8.7 (https://github.com/electron/electron/releases/tag/v39.8.7), 40.9.0 (https://github.com/electron/electron/releases/tag/v40.9.0), 41.2.0 (https://github.com/electron/electron/releases/tag/v41.2.0), or 42.0.0-beta.1 (https://github.com/electron/electron/releases/tag/v42.0.0-beta.1). The patch in PRs #50665-50668 adds a compile-time kValidDockStates allowlist (bottom, left, right, undocked) to inspectable_web_contents.cc and defaults to 'right' on invalid input, eliminating the injection surface entirely. Where patching is not immediately possible, apply the documented workaround: only pass fixed allowlisted string literals ('right', 'bottom', 'undocked', 'detach') as the mode argument to openDevTools(), and never expose the openDevTools API to or allow it to be called by untrusted web content or webview-embedded pages. If DevTools are not required in production builds, setting webPreferences.devTools: false eliminates the attack surface without functional trade-offs for end users.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 4 packages in npm, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Electron is a cross-platform desktop application framework that co-embeds Chromium (for web rendering) and Node.js (for system access). The vulnerability originates in shell/browser/ui/inspectable_web_contents.cc, specifically InspectableWebContents::SetDockState() and the LoadCompleted() path. The mode option of webContents.openDevTools() controls how the DevTools panel docks (right, bottom, undocked, detach) and was passed directly, without an allowlist check, to the Chromium DevTools frontend JavaScript environment. Because this value is treated as data but reaches a JavaScript context that can interpret it as code, the root cause is CWE-94 (Improper Control of Generation of Code / Code Injection). The critical amplifier is that Electron's DevTools context, unlike a normal renderer, retains direct Node.js API access when the app runs unsandboxed - meaning code executing there can perform filesystem I/O, spawn child processes, and make network calls at the OS level. CPE: cpe:2.3:a:electron:electron:*:*:*:*:*:*:*:*.
Know when Electron gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N
Webview-embedded content requires no elevated privileges (PR:N), unsandboxed Node.js access from DevTools constitutes a scope change to the host (S:C), and AC:H reflects the non-default unsandboxed configuration prerequisite.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1, the mode option of webContents.openDevTools() was not sanitized before use by the DevTools frontend. If an attacker can influence this value, script under their control may run in the DevTools context, which in unsandboxed configurations has access to Node.js, including when untrusted input reaches the mode argument of openDevTools() or untrusted content calls openDevTools() on a webview it embeds. This issue is fixed in 39.8.7, 40.9.0, 41.2.0, and 42.0.0-beta.1.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
GitHub Electron versions 1.8.2-beta.3 and earlier, 1.7.10 and earlier, 1.6.15 and earlier has a vulnerability in the pro
Remote code execution in 5ire 0.15.2 and earlier arises because the desktop AI assistant renders Mermaid diagrams with s
Cross-site scripting in DeepChat's Mermaid diagram renderer escalates to full remote code execution on affected desktop
Remote code execution in DeepChat 0.5.1 and below is possible through a cross-site scripting flaw in Mermaid diagram ren
Stored cross-site scripting in SiYuan through 3.8.4 lets an attacker who can set a notebook name containing an HTML payl
GitHub Electron before 1.6.8 allows remote command execution because of a nodeIntegration bypass vulnerability. Rated hi
GitHub Electron 1.7.15, 1.8.7, 2.0.7, and 3.0.0-beta.6, in certain scenarios involving IFRAME elements and "nativeWindow
Electron version 1.7 up to 1.7.12; 1.8 up to 1.8.3 and 2.0.0 up to 2.0.0-beta.3 contains an improper handling of values
electron-updater allows for automatic updates for Electron apps. Rated high severity (CVSS 7.5), this vulnerability is r
Cross-origin read bypass in Electron's custom protocol handler exposes sensitive application data to remote pages via fe
Native code execution outside the Chromium sandbox is achievable in Electron prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity
EUVD-2026-53566
GHSA-4f78-qhmw-8j8m
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB