EUVD-2026-53545
GHSA-f2r8-jv7c-xqmp
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAttacker distributes malicious DevTools extension
-
DeliveryDeveloper installs extension and opens DevTools on untrusted-content window
-
ExploitExtension executes JavaScript in DevTools renderer context
-
ExecutionExtension calls sendMessageToEmbedder showItemInFolder with attacker-chosen executable path
-
PersistElectron main process invokes platform_util::OpenPath on arbitrary path
-
ImpactNative executable runs outside Chromium sandbox with host user privileges
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization OS command sanitization, avoid shell exec
MITRE ATT&CK
2 techniques across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Two independent conditions must both be present simultaneously. First, the attacker must have an established means of executing arbitrary JavaScript inside the Electron app's DevTools frontend - the advisory explicitly names a malicious DevTools extension as the primary vector; a separate renderer compromise of the DevTools tab would also qualify, but requires its own exploit chain. Second, DevTools must be actively open for a BrowserWindow that either loads untrusted web content or has had an untrusted DevTools extension loaded into it; apps that never open DevTools in this context are explicitly stated as unaffected by the vendor. The CVSS PR:H metric confirms that attacker-controlled script execution within the DevTools context (a privileged, non-sandboxed communication channel) is a hard prerequisite. UI:R confirms that a human user must take the deliberate action of opening DevTools. Together these conditions limit the practical attack surface to developer or power-user environments that process untrusted content with DevTools open, not general end-user deployments. |
| Impact | The CVSS 3.1 vector (AV:L/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N, score 6.9) is well-calibrated to the actual exploitation difficulty: local attack vector, high complexity, high privilege requirement, and mandatory user interaction all gate the attack, while the Scope:Changed metric correctly captures the sandbox escape consequence. No EPSS score is present in the source data, but the combination of AC:H and PR:H strongly suggests a low real-world exploitation probability; this is not a drive-by or mass-exploitation scenario. There is no CISA KEV entry and no POC exploit code identified. SSVC signals classify this as non-automatable exploitation with a targeted technical impact - appropriate for scheduled patching rather than emergency response in most environments. The primary realistic risk is to developer workstations that use third-party or community DevTools extensions against windows that process untrusted content, not to end users of typical Electron applications. The S:C/C:H/I:H combination does make sandbox escape the standout consequence when conditions are met. |
| Exploit ScenarioDerived | A developer installs a malicious Chromium DevTools extension distributed through a compromised extension registry or social engineering. When the developer opens DevTools against a BrowserWindow that loads third-party or user-generated content, the extension executes JavaScript in the DevTools renderer context and calls DevToolsAPI.sendMessageToEmbedder('showItemInFolder', ['/path/to/attacker.exe'], null), causing the Electron main process to invoke platform_util::OpenPath() on an arbitrary executable, running native code outside the Chromium sandbox with the privileges of the host user. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 05, 2026
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-beta.3 via the DevTools 'reveal in file manager' handler, which incorrectly forwarded attacker-supplied paths to the OS shell-open primitive rather than a safe folder-reveal call. Exploitation requires an attacker to already control JavaScript execution within the DevTools frontend - most plausibly through a malicious DevTools extension - while DevTools is open against a window loading untrusted content. No public exploit code exists and the vulnerability is not listed in CISA KEV; patched releases are available across all active Electron stable and beta branches.
RemediationAI
Upgrade to Electron 39.8.9, 40.9.2, 41.2.1, or 42.0.0-beta.3; the patched release tags are available at https://github.com/electron/electron/releases/tag/v39.8.9, /v40.9.2, /v41.2.1, and /v42.0.0-beta.3 respectively. The upstream fixes are confirmed merged via PR #50937 and PR #50938. If immediate upgrade is not feasible, the vendor-documented workaround is to never open DevTools for BrowserWindows that load untrusted content and to avoid loading untrusted DevTools extensions; this eliminates the exploitation surface entirely but may disrupt developer workflows that inspect untrusted content in-app. No other compensating controls are identified in the advisory.
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 an npm package (CPE: cpe:2.3:a:electron:electron:*:*:*:*:*:*:*:*) that wraps Chromium and Node.js to power cross-platform desktop applications. The vulnerable component is InspectableWebContents::ShowItemInFolder in shell/browser/ui/inspectable_web_contents.cc. The DevTools frontend communicates with the Electron main process via DevToolsAPI.sendMessageToEmbedder(); the 'showItemInFolder' message handler received a filesystem path from the DevTools renderer and passed it to platform_util::OpenPath() - a native OS shell-open call that can launch and execute files - rather than the semantically correct platform_util::ShowItemInFolder(). Because the DevTools renderer is web-hosted and can be attacker-influenced, this constitutes CWE-78 (Improper Neutralization of Special Elements used in an OS Command) at the process boundary between the sandboxed renderer and the privileged main process. The fix, visible in PR #50937, gates the call behind a check against kDevToolsFileSystemPaths, the set of workspace folders the user has explicitly registered; paths not under a registered workspace root are silently discarded rather than forwarded to the OS.
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:L/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N
Exploitation requires attacker-controlled script already running in the privileged DevTools context (PR:H, AC:H) and explicit user action to open DevTools (UI:R); sandbox escape drives S:C with full C and I impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3, the DevTools reveal in file manager action could launch the target file rather than reveal it. An attacker with a separate means of running script inside the DevTools frontend, such as a malicious DevTools extension, could use showItemInFolder handling to execute native code outside the sandbox when DevTools is opened for windows exposed to untrusted content or untrusted DevTools extensions. This issue is fixed in 39.8.9, 40.9.2, 41.2.1, and 42.0.0-beta.3.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
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
OS command injection occurs when an application passes unsanitized user input directly into system shell commands.
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
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass. Rated critical severity
Privilege escalation in the Electron framework lets a <webview> guest grant itself Node.js integration inside its Web Wo
Exploit-DB