EUVD-2026-107374
GHSA-x562-297c-g43g
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessEmbed untrusted cross-origin iframe in app
-
DeliveryLure user gesture to trigger request
-
ExploitIframe calls requestPointerLock()
-
ExecutionHandler sees top-level origin, not iframe
-
ImpactPermission granted under trusted identity
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Origin validation
|
| Exploitation Conditions | Exploitation requires an Electron app (versions prior to 42.11.9 / 43.7.6 / 44.5.0 / 45.0.0-alpha.13) that (1) embeds untrusted cross-origin iframe content and (2) uses session.setPermissionRequestHandler() to grant pointerLock permission based on the requesting origin/frame identity. The underlying technical precondition is that the requesting iframe shares a render process/widget with its parent - i.e. same-site cross-origin iframes under site-per-process, or any iframe when site isolation is disabled - so the browser cannot distinguish the requesting frame from the local root. A user gesture is required to initiate pointer lock (UI:R). LIMITING FACTORS: applications that deny pointerLock for untrusted embedded content are explicitly NOT affected; apps that do not embed untrusted iframes are not affected; and the impact is confined to mis-attributed pointer-lock permission grants (no confidentiality impact). |
| Impact | This is a genuinely low-to-moderate priority issue despite the 5.4 CVSS, and the signals are consistent in pointing to limited real-world risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L) describes a network-reachable, unauthenticated flaw requiring user interaction, with no confidentiality impact and only low integrity/availability impact - matching a permission-identity-confusion bug rather than code execution or data theft. No EPSS score, KEV listing, or public POC was provided in the intelligence, so there is no evidence of active exploitation or weaponization; exploitation status is best characterized as no public exploit identified at time of analysis. Critically, the vulnerability is NOT exploitable against default or typical Electron apps: it only matters for applications that both embed untrusted cross-origin iframe content AND grant pointerLock based on the requesting origin, and the vendor explicitly states applications that deny pointerLock for untrusted embedded content are unaffected. The CWE-346 (Origin Validation Error) classification aligns with the described confusion between the requesting frame's and top-level frame's requestingUrl/isMainFrame values. Net: a real, confirmed bug worth patching during normal maintenance cycles, but not an emergency for most deployments. |
| Exploit ScenarioDerived | An Electron application embeds untrusted third-party web content in a cross-origin iframe (sharing a process with the parent, e.g. same-site cross-origin under site-per-process or any iframe without site isolation) and uses session.setPermissionRequestHandler() to grant pointerLock based on the requesting origin. A malicious embedded page calls Element.requestPointerLock(), and because the handler receives the top-level frame's trusted requestingUrl and isMainFrame instead of the iframe's, the app grants pointer lock under the trusted top-level identity. No public exploit code was identified; exploitation requires a user gesture (UI:R) to initiate the lock. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Electron mis-attributes pointerLock permission requests originating from cross-origin iframes, causing session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of the actual requesting frame's. Applications that embed untrusted iframe content and grant pointer lock based on the requesting origin can therefore be tricked into granting the permission under the top-level page's identity, allowing an embedded attacker-controlled frame to capture the pointer (integrity and availability impact only, no confidentiality impact). Exploitation requires a user gesture and an affected Electron version prior to 42.11.9, 43.7.6, 44.5.0, or 45.0.0-alpha.13; apps that already deny pointerLock for untrusted content are not affected. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, so real-world risk is limited to the narrow population of apps whose permission handlers trust origin strings for pointer lock.
RemediationAI
Upgrade to Electron 42.11.9, 43.7.6, 44.5.0, or 45.0.0-alpha.13 (or later) as documented in GHSA-x562-297c-g43g and the linked release tags; the fix is delivered through PR #54432 with follow-up pull requests #54463 through #54466 and commits 076c749, 0b680cf, 1755ee5, 4073e9f and a48e6ea. If an immediate upgrade is not possible, the highest-value compensating control is to stop authorizing pointerLock by origin inside setPermissionRequestHandler(): deny pointerLock unconditionally for any content not served from a first-party origin you fully control, or reject any request where isMainFrame is false or where the requestingUrl does not exactly match the top-level document's URL - the trade-off is that legitimate same-origin iframe use cases requiring pointer lock will break. A second, narrower workaround is to disable site isolation so behavior is at least uniform and detectable, or conversely to move embedded third-party content into a separate BrowserWindow/WebContents with its own session, so the untrusted frame never shares a widget with the trusted top-level page; this costs additional process memory and complicates IPC between the windows. Blocking pointer lock entirely at the app level (returning deny for the pointerLock permission) removes the attack surface at the cost of losing the mouse-capture feature, and removing untrusted iframe embedding from the app is the most robust option where the feature is not essential.
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 supplies Blink/Chromium's pointer lock plumbing to application code through session.setPermissionRequestHandler(), classifying the bug as CWE-346 (Origin Validation Error). In Chromium, Element.requestPointerLock() is delivered to the browser over the WidgetInputHandlerHost of the requesting frame's local root widget, so the browser process only learns which widget asked, not which frame. Frames that share a render process with their parent - same-site cross-origin iframes under site-per-process, or any iframe when site isolation is disabled - share that widget, making the request indistinguishable from one issued by the local root document. Chrome keys pointer lock on the top-level tab and never needed this distinction, but Electron surfaces the requesting origin and isMainFrame flag to app-level permission handlers, so the mis-attribution becomes a security-relevant origin confusion. The upstream fix in PR #54432, 'fix: plumb the requesting frame through pointer lock requests', threads the requesting frame's blink::LocalFrameToken through InputRouterClient, InputRouterImpl, RenderInputRouter and RenderInputRouterClient, validates in WebContentsImpl that the token names a live frame in the widget's process whose local root is that widget, stores it alongside pointer_lock_widget_, and exposes it via WebContentsImpl::GetPointerLockRequestingFrame(). Related upstream tracking is crbug.com/492211919, which shares the same local-root-only limitation for sandbox flag checks.
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:L/PR:N/UI:R/S:U/C:N/I:L/A:L
Network-reachable untrusted web content (AV:N/PR:N) needs a user gesture (UI:R) and the specific process-sharing/app-config conditions (AC:H); impact is limited to spoofed permission identity (I:L) and cursor capture (A:L), no data disclosure (C: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.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13, pointerLock permission requests from some cross-origin iframes caused session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of those of the requesting frame. An application that embeds untrusted iframe content and grants pointer lock based on the requesting origin could therefore grant the permission under the top-level page's identity. Applications that deny pointerLock for untrusted embedded content are not affected. This issue is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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
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