EUVD-2026-107361
GHSA-997q-gvvc-jwmx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLoad untrusted web content in Electron window
-
DeliveryOpen popup or trigger server redirect to external-protocol URL
-
ExploitInitiating document disposed mid-navigation
-
ExecutionrequestingUrl misattributed to trusted origin
-
PersistPermission handler approves openExternal
-
ImpactOS-registered application launched by untrusted content
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Origin validation
|
| Exploitation Conditions | Exploitable only when the embedding Electron application BOTH grants OPEN_EXTERNAL permission based on the requestingUrl/origin supplied to session.setPermissionRequestHandler AND allows untrusted content to open or navigate windows. The attack also requires a timing/redirect condition where the initiating document no longer exists when the external-protocol request reaches the browser (e.g. a popup whose initiator navigated away, or a server-side redirect to the external URL), which is reflected in AC:H. Apps that deny openExternal outright, do not key approval on origin, or do not render untrusted content are NOT affected regardless of version. No end-user interaction beyond visiting attacker content is strictly required, and no authentication is needed (PR:N). |
| Impact | This is a moderate, conditionally-exploitable origin-confusion flaw (CWE-346) rather than a top-priority emergency. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N = 5.4 Medium) is internally consistent with the description: it is network-reachable and needs no authentication, but AC:H correctly reflects that exploitation depends on a specific, non-default application design plus a redirect/navigation timing window where the initiating document is gone. No EPSS score, KEV listing, or POC was provided in the input, so there is no signal of active exploitation or weaponization - no public exploit identified at time of analysis. The most important caveat is that this is NOT a flaw exploitable against a default Electron app: it only matters when the embedding application (a) grants openExternal based on the requestingUrl/origin passed to setPermissionRequestHandler AND (b) permits untrusted content to open or navigate windows. Where that combination exists, the S:C scope change (crossing from web content into an OS-registered external application) makes the impact meaningful despite the low CVSS. The 'Information Disclosure' tag understates the issue - the real impact is unauthorized external-application launch via origin spoofing, not data leakage. |
| Exploit ScenarioDerived | In an Electron app that allows untrusted/third-party web content in a window and approves openExternal requests by checking the requestingUrl, an attacker-controlled page initiates a navigation to an external-protocol URL (e.g. via a popup or server redirect) and arranges for the initiating document to be gone when the request reaches the browser. Electron then attributes the launch to a trusted document's origin, so the permission handler approves it and an OS-registered external application is launched on behalf of the untrusted content. No public exploit code was identified in the provided intelligence. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Origin confusion in Electron's external protocol handling lets a launch request be attributed to a document other than the one that actually initiated it, so the requestingUrl handed to session.setPermissionRequestHandler can name trusted content for a launch requested by untrusted content. Applications running Electron prior to 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5 are exposed only if they both grant openExternal based on that requesting origin and permit untrusted content to open or navigate windows, in which case attacker-supplied content may reach an OS-registered external application such as a mail client or custom URL handler. Exploitation additionally depends on a timing condition where the initiating document is gone when the request reaches the browser (a popup whose opener navigated away, or a server redirect to the external URL), which is why the assessed vector carries AC:H; no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (CISA KEV).
RemediationAI
Upgrade to Electron 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5 (or later) as documented in advisory GHSA-997q-gvvc-jwmx and the corresponding release tags; the fixes land via PRs 53682, 53696, 53697, 53698, 53699 and commits 25057643bf6d9a20bad69e45707551ccf546f5ce, 8aa5414f73792ed3b2e3f9ab6391b1832e6dc2c3, 92a783952891805f2f82f344c40a6917b98a7d98, e0a20d5277b567aea8603f8e9852a4341407a586, and e3a400911084537bce7380ffea8af939572ce8dd. If upgrading cannot be done immediately, the decisive compensating control is to stop trusting requestingUrl for OPEN_EXTERNAL: deny external-protocol launches outright in setPermissionRequestHandler (trade-off: legitimate links to mail clients, SSO handlers, or custom URL schemes stop working) or gate approval on a hard-coded allowlist of the application's own trusted webContents/origins instead of the origin string in the permission details. Additionally, deny window opening for untrusted content via setWindowOpenHandler returning {action: 'deny'} and avoid loading remote or third-party content into BrowserWindows that can trigger external protocols (trade-off: breaks embedded browsing or OAuth popup flows that rely on window.open). Applications that already deny openExternal unconditionally, do not key approval on origin, or never render untrusted content need no emergency action beyond routine upgrade scheduling.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Electron builds on Chromium's content layer, and external protocol launches flow through ElectronBrowserClient::HandleExternalProtocol into HandleExternalProtocolInUI and then WebContentsPermissionHelper::RequestOpenExternalPermission, which ultimately surfaces to embedders as the OPEN_EXTERNAL permission in session.setPermissionRequestHandler. The root cause is a CWE-346 origin validation error: when the initiating RenderFrameHost had already been disposed of or belonged to a different frame than the navigation (for example a popup or a redirect chain), the code fell back to the navigating WebContents' current main frame and stamped details["requestingUrl"] with render_frame_host->GetLastCommittedURL(), declaring that frame responsible. An attacker-influenced document could therefore cause the permission details to describe a trusted origin and main-frame status rather than the untrusted initiator. The upstream fix (PRs 53682, 53696, 53697, 53698, 53699; commits 25057643, 8aa5414f, 92a78395, e0a20d52, e3a40091) introduces an ExternalProtocolRequester carrying the initiator document's last committed origin and main-frame-ness captured at the moment the request reaches the browser, plus an initiating_origin derived from server redirects, and passes that attribution into RequestOpenExternalPermission so ElectronPermissionManager only computes requestingUrl/isMainFrame from the RenderFrameHost when they are not already supplied. The same patch set also corrects user_gesture propagation, which had been hard-coded to false when forwarding external-protocol permissions.
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:N/UI:N/S:C/C:L/I:L/A:N
Network-reachable untrusted web content needs no auth (PR:N), but a redirect/disposed-document race plus origin-based app config make it AC:H; launching an OS app is a scope change (S:C) with limited C/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 versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, requests to open external protocol URLs could be attributed to a document other than the one that initiated them, causing the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content. An application that grants openExternal based on the requesting origin and allows untrusted content to open or navigate windows could therefore allow that content to launch an OS-registered external application. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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
Exploit-DB