EUVD-2026-107368
GHSA-2p8c-gr87-2676
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to untrusted content in Electron app
-
DeliveryContent opens crafted link in new window
-
ExploitNavigation misclassified as same-site
-
ExecutionSameSite=Strict cookies attached cross-site
-
ImpactForge credentialed CSRF action on target site
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V3 - Web Frontend Security Anti-CSRF tokens, SameSite cookies
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an Electron application that (1) loads untrusted content and (2) permits that content to open new windows/popups - which Electron disables by default - and additionally the targeted external site must rely on SameSite cookies (e.g., SameSite=Strict) rather than tokens for CSRF protection. The attack is further limited by required user interaction: the victim must open the attacker's link into a new window (via window.open, target="_blank", or a modifier/middle-click). These limiting factors (non-default popup allowance, untrusted-content loading, victim interaction, and SameSite-dependent target) make realistic exploitation narrow despite the network attack vector. |
| Impact | This is a genuinely low-to-moderate priority issue despite being a real cross-site request forgery bypass (CWE-352). The provided CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N) yields a base score of 4.2 (Medium), and the individual metrics all point toward limited real-world risk: AC:H reflects that exploitation depends on a specific, non-default application posture, and UI:R requires the victim to actively open a link into a new window. The impact is intentionally scoped to C:L/I:L/A:N - the flaw does not grant code execution or data disclosure directly, it only causes SameSite=Strict cookies to be sent and misrepresents Sec-Fetch-Site on a link-opened top-level navigation, weakening a defense-in-depth control that a target site relies on for CSRF protection. No EPSS score, KEV entry, or SSVC decision data was supplied, so probabilistic and decision-framework signals cannot be weighed; based on the signals present, there is no public exploit identified at time of analysis. The references consist entirely of the vendor advisory, fix PRs, patch commits, and release tags - i.e., remediation artifacts, not proof-of-concept exploit code. The signals are internally consistent (network vector is appropriate because the forged request reaches another site, and high complexity matches the conditional configuration), so no conflicts require vendor verification; the chief limitation is that risk is entirely contingent on the embedding application's configuration rather than on Electron in isolation. |
| Exploit ScenarioDerived | An Electron application that renders untrusted web content and allows that content to open new windows is tricked into letting the attacker-controlled page open a link into a new top-level window. Because Electron treated this as an application-initiated navigation, the resulting request is classified as same-site, so the victim's SameSite=Strict cookies are attached to a cross-site request against a target that depends on those cookies for CSRF protection, letting the attacker perform a state-changing action as the victim. No public exploit code was identified, and the attack requires the victim to open the link (UI:R). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Cross-site request forgery bypass in Electron before 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6 lets untrusted content loaded by a desktop app make credentialed requests to other sites by corrupting how the framework attributes the initiator of links opened into new windows. Because Electron re-issued such top-level navigations as application-initiated loads rather than preserving the originating page's identity, the request could be judged same-site, causing SameSite=Strict cookies to be attached and Sec-Fetch-Site to omit the true initiator. Rated CVSS 4.2 (AV:N/AC:H/PR:N/UI:R, C:L/I:L/A:N), exploitation requires an app that both loads untrusted content and allows it to open popups (popups are disabled by default), a victim who opens the crafted link into a new window, and a target site that depends on SameSite cookies rather than anti-CSRF tokens; no public exploit code identified at time of analysis and the issue is not in CISA KEV.
RemediationAI
Vendor-released patch: upgrade to Electron 42.11.3, 43.7.0, 44.3.0, or 45.0.0-alpha.6 (or later) as documented in advisory GHSA-2p8c-gr87-2676 and the corresponding release tags; the fix makes link-opened windows inherit the initiator's SiteInstance and applies the popup policy to that code path, so no application code change is strictly required once the runtime is updated. Where upgrading is delayed, set a window open handler that returns {action: 'deny'} (or otherwise blocks window.open/target="_blank" from untrusted frames) before loading third-party content - this closes the attack path entirely but will break legitimate in-app popup flows relying on those links. Keeping popups disabled (the default) and refusing to load untrusted remote content in privileged windows also eliminates the prerequisite conditions. On the server side, sites that may be targeted should not rely on SameSite cookies alone for CSRF defense; adding per-request anti-CSRF tokens neutralizes the bypass for downstream services regardless of the client's Electron version, at the cost of application-level implementation work.
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 delegates navigation to Chromium's content layer. When a renderer requests a link be opened in a new window (modifier-click, middle-click, target="_blank", or a form post routed through content::WebContents::OpenURLFromTab), Electron previously created the guest window and called window.loadURL() on it - a browser-initiated load. That path discards the initiating frame's SiteInstance, origin, and user-gesture context, so the resulting top-level request was evaluated by Chromium's SameSite cookie logic and Sec-Fetch metadata as if the application itself had issued it. Requests appearing same-site to the destination let SameSite=Strict/Lax cookies ride along and made Sec-Fetch-Site unreliable for server-side CSRF checks - the classic CWE-352 cross-site request forgery weakness reborn at the framework layer. The fix threads a new navigate callback through guest-window-manager.ts and web-contents.ts so the new window is started with NavigationController::LoadURLParams constructed from the original OpenURLParams, preserving source_site_instance (with a browser-context guard, since a SiteInstance cannot cross browser contexts). The patch also extends the embedder's popup policy to this path: WebContents::OpenURLFromTab now consults WebContentsPreferences::ShouldDisablePopups() and returns nullptr, so link-opened windows obey the same policy as window.open(), and the webview-tag documentation was updated to say popups cover both cases.
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:R/S:U/C:L/I:L/A:N
AV:N because the forged request targets another site; AC:H as it needs a non-default app that loads untrusted content and allows popups; PR:N but UI:R since the victim must open the link; C/I:L for a CSRF cookie bypass, 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.6, Electron treated pages opened into a new window from links as application-initiated navigations instead of preserving the page containing the link as the initiator. The resulting top-level request could be classified as same-site, causing SameSite=Strict cookies to be sent and Sec-Fetch-Site not to identify the initiating page. An application that loads untrusted content and permits it to open new windows could therefore allow that content to make a credentialed request to another site that relies on SameSite cookies for CSRF protection. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6.
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
Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.
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