EUVD-2026-107347
GHSA-fw47-9c62-h3vw
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLoad untrusted content in delegated cross-origin iframe
-
DeliveryIframe requests hid/usb device access
-
ExploitPermission check receives top-level origin instead of iframe origin
-
ExecutionOrigin-based logic grants access to embedded frame
-
ImpactUntrusted frame reads/writes connected device
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Origin validation
|
| Exploitation Conditions | Exploitation requires a very specific application configuration, all of which must be true: (1) the Electron app delegates the 'hid' or 'usb' permission to a cross-origin, untrusted iframe (via permissions policy); (2) the app's setPermissionCheckHandler grants device access using origin-based logic (trusting the reported origin); and (3) the app runs a version prior to 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5. The flaw is that the handler received the top-level frame's origin/details instead of the requesting iframe's. Limiting factors: this is not a default configuration - most applications do not expose HID/USB to untrusted embedded content; a vulnerable HID/USB device must also be connected and accessible for impact to be realized. Apps that make device decisions on requestingOrigin correctly or do not delegate these permissions are unaffected. |
| Impact | This is a genuine but narrowly-scoped origin-validation flaw (CWE-346), not a broad critical. The provided 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: the attack rides on web content loaded in an iframe (AV:N), requires no authentication (PR:N) or user interaction (UI:N), but carries High attack complexity (AC:H) because the victim application must have explicitly delegated hid/usb to a cross-origin untrusted iframe AND implemented device-access decisions using origin-based logic in setPermissionCheckHandler. The Scope:Changed and Low C/Low I with A:N are reasonable - the bug lets an embedded frame inherit the top-level page's device-access decision, exposing data from and commands to HID/USB devices, but not availability. No EPSS score, no CISA KEV entry, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict: a Medium CVSS, absence of KEV/POC, and a precondition-heavy exploitation path all point to a low real-world priority - patch on normal cadence rather than emergency. The dominant mitigating fact is that the vulnerable behavior only manifests in applications with an unusual and already-risky configuration (delegating device permissions to untrusted cross-origin iframes), which is not Electron's default. |
| Exploit ScenarioDerived | An Electron application embeds untrusted third-party web content in a cross-origin iframe and has delegated hid or usb permission to it, granting device access based on the requesting origin. Because the permission check incorrectly reports the top-level frame's origin instead of the iframe's, the embedded untrusted frame is treated as the trusted top-level page and is granted access to a connected HID or USB device. No public exploit code is identified at time of analysis, and the attack requires the application-specific delegation and origin-based logic to already be in place. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Electron's HID and USB permission checks mishandle the requesting frame's origin, so an app whose setPermissionCheckHandler authorizes devices by origin can be tricked into granting WebHID/WebUSB access to a cross-origin untrusted iframe that was never meant to receive it. Only applications that both delegate the 'hid' or 'usb' permission to an untrusted cross-origin frame via permissions policy and make device decisions on the reported origin are exposed, and a matching device must also be attached; default configurations are not affected. Unauthenticated remote attackers can trigger the logic remotely (CVSS 3.1 AV:N/PR:N), but with high attack complexity and low confidentiality/integrity impact scored at 5.4 with a scope change. No public exploit code and no confirmed active exploitation were identified at time of analysis; fixed in 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.
RemediationAI
Vendor-released patch: upgrade to Electron 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.5 (release tags v42.11.3, v43.7.0, v44.3.0, v45.0.0-alpha.5), and follow the GHSA-fw47-9c62-h3vw advisory; downstream applications must rebuild and reship their Electron binary since the fix lives in the runtime, not app code. Where upgrading is not immediately possible, stop delegating the 'hid' and 'usb' permissions to cross-origin or untrusted iframes via permissions policy - the trade-off is that legitimate embedded HID/USB flows stop working. As a second compensating control, harden setPermissionCheckHandler (and setPermissionRequestHandler) to authorize devices only when the check is made on behalf of the top-level document, rejecting requests where isMainFrame is false or where requestingOrigin differs from the app's own trusted origin; the trade-off is that any intentionally supported cross-origin device delegation is refused. Also verify the handler no longer derives trust from the webContents argument alone, since it is now documented to be the top-level WebContents for subframe checks, and audit any stored HID/USB grants created under the old behavior before considering them trustworthy.
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 wraps Chromium's content layer, where HidService and WebUsbServiceImpl are constructed with the primary main frame's committed origin rather than the requesting frame's origin. Because Electron grants, stores, checks, and revokes device permissions per requesting document, that mismatch meant every delegate call made on behalf of a document (CanRequestDevicePermission, HasDevicePermission, RevokeDevicePermission[WebInitiated], IsFidoAllowedForOrigin, AdjustProtectedInterfaceClasses) and the OnPermissionRevoked comparison operated on the top-level origin instead of the iframe's origin. The result is CWE-346 (Origin Validation Error): the embedder's setPermissionCheckHandler received the top-level frame's origin and details, so origin-based trust decisions were evaluated against the wrong principal, and a delegated cross-origin iframe could inherit device access intended for the top page. The upstream fixes add a RenderFrameHost* parameter to HidDelegate/UsbDelegate CanRequestDevicePermission so the 'can request' step matches the sibling methods that already take a frame, and key the HID/USB document services on the requesting frame's origin; Chrome's own delegates ignore the new argument, so the Electron-specific permission model is what the change targets. Documentation for session.setPermissionRequestHandler/setPermissionCheckHandler was updated to clarify that webContents is the top-level WebContents for subframe checks and that requestingOrigin, requestingUrl, and isMainFrame must be used to identify the asking frame.
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
Web-delivered (AV:N) with no auth or interaction, but AC:H because the app must delegate hid/usb to an untrusted iframe and use origin-based grants; S:C as it crosses the frame origin boundary, C:L/I:L for device read/write, A:N.
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, hid and usb permission checks made from an iframe caused setPermissionCheckHandler to receive the top-level frame's origin and details instead of the requesting frame's. An application that delegated hid or usb to a cross-origin untrusted iframe and allowed device access with origin-based logic could therefore grant that embedded frame access intended for the top-level page. 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