Skip to main content

Electron CVE-2026-70608

| EUVDEUVD-2026-53564 HIGH
Protection Mechanism Failure (CWE-693)
2026-08-05 https://github.com/electron/electron GHSA-9f4c-93c8-jc8g
7.2
CVSS 3.1 · Vendor: https://github.com/electron/electron
Share

Severity by source

Vendor (https://github.com/electron/electron) PRIMARY
7.2 HIGH
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
vuln.today AI
7.2 HIGH

Network-delivered iframe content requires no app privileges; untrusted event auto-fires with no user gesture; scope changes as sandbox boundary is crossed; no availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

Primary rating from Vendor (https://github.com/electron/electron).

CVSS VectorVendor: https://github.com/electron/electron

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
None

Lifecycle Timeline

3
Source Code Evidence Fetched
Aug 05, 2026 - 17:51 vuln.today
Analysis Generated
Aug 05, 2026 - 17:51 vuln.today
CVE Published
Aug 05, 2026 - 17:27 github-advisory
HIGH 7.2

DescriptionCVE.org

Impact

A sandboxed iframe without the allow-popups keyword could still open a new window (or trigger setWindowOpenHandler) with no user interaction, because new-window navigations taking the OpenURL path did not apply the iframe sandbox popup restriction.

Apps that embed untrusted content in sandboxed iframes and rely on the absence of allow-popups to prevent window creation are affected. Apps that deny window creation in setWindowOpenHandler, or that do not embed untrusted content in sandboxed iframes, are not affected.

Workarounds

Return { action: 'deny' } from setWindowOpenHandler for any content you do not trust, rather than relying on the iframe sandbox alone.

Fixed Versions

  • 42.0.1
  • 41.10.3
  • 39.8.10

For more information

If you have any questions or comments about this advisory, email Electron at [security@electronjs.org](mailto:security@electronjs.org)

AnalysisAI

Sandboxed iframe popup restriction bypass in Electron allows untrusted iframe content to open new windows or trigger setWindowOpenHandler without user interaction, despite the allow-popups keyword being absent from the sandbox attribute. Electron versions prior to 42.0.1, 41.10.3, and 39.8.10 are affected. The bypass occurs because FrameLoader::StartNavigation and WebContents::OpenURLFromTab in the OpenURL code path did not check the iframe's sandbox popup flags, permitting emulated Ctrl+click events from untrusted JavaScript to create new browsing contexts. No public exploit or CISA KEV listing is confirmed at time of analysis, but the patch diff includes a working proof-of-concept test.

Technical ContextAI

Electron wraps Chromium's Blink rendering engine and exposes it through a Node.js-based desktop application framework (pkg:npm/electron). The HTML sandbox attribute restricts iframe capabilities; omitting allow-popups is supposed to prevent the iframe from opening new windows. The root cause (CWE-693, Protection Mechanism Failure) is a missing sandbox flag check in two Chromium/Electron code paths: FrameLoader::StartNavigation (Blink-level) and WebContents::OpenURLFromTab (Electron-level). When an untrusted event such as a programmatically dispatched Ctrl+click MouseEvent triggers a new-tab navigation (kNavigationPolicyNewForegroundTab), the code routed through OpenURL skipped the WebSandboxFlags::kPopups check entirely. The fix adds an explicit check in both frame_loader.cc (for kFromUntrustedEvent navigation policy) and electron_api_web_contents.cc (checking SandboxFlags::kPopups on the initiating frame tree node before allowing OpenURLFromTab to proceed). The affected npm package ranges are: >= 42.0.0-alpha.1, < 42.0.1; >= 40.0.0-alpha.1, < 41.10.3; and < 39.8.10.

RemediationAI

Upgrade Electron to the appropriate patched release: 42.0.1, 41.10.3, or 39.8.10 depending on your current release line. Patches are merged via pull requests #51437, #51438, and #51439 against the corresponding branches. Where immediate upgrade is not feasible, the vendor-recommended workaround is to return { action: 'deny' } from setWindowOpenHandler for any content that is not fully trusted - this ensures even if the sandbox bypass fires, the resulting window creation is blocked at the Electron API layer. This workaround has no functional side effects for applications that already intend to deny external window creation, but may suppress legitimately expected popups in applications that selectively allow them; review your setWindowOpenHandler logic carefully before applying it broadly. Relying solely on the iframe sandbox attribute without allow-popups as a popup prevention mechanism should be treated as insufficient on unpatched versions.

Share

CVE-2026-70608 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy