Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-70608

CVE-2026-70608: Electron Sandbox Bypass Vulnerability

CVE-2026-70608 is a sandbox bypass flaw in Electron that allows sandboxed iframes to open windows without user interaction, bypassing allow-popups restrictions. This article covers technical details, affected versions, and patches.

Published:

CVE-2026-70608 Overview

Electron is a cross-platform desktop application framework built on Chromium and Node.js. CVE-2026-70608 is a security bypass vulnerability [CWE-693] affecting Electron versions prior to 39.8.10, 41.10.3, and 42.0.1. A sandboxed iframe without the allow-popups keyword could still open a new window or trigger setWindowOpenHandler without user interaction. The flaw exists because new-window navigations following the OpenURL path did not enforce the iframe sandbox popup restriction. Applications that embed untrusted content in sandboxed iframes and rely on the absence of allow-popups to prevent window creation are directly exposed.

Critical Impact

Untrusted content embedded in a sandboxed iframe can create new browsing contexts without user interaction, bypassing the sandbox popup restriction and enabling window creation in host Electron applications.

Affected Products

  • Electron versions prior to 39.8.10
  • Electron versions prior to 41.10.3
  • Electron versions prior to 42.0.1

Discovery Timeline

  • 2026-08-05 - CVE-2026-70608 published to NVD
  • 2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-70608

Vulnerability Analysis

The vulnerability resides in how Electron handles new-window navigations initiated from within sandboxed iframes. HTML sandbox flags allow developers to constrain the capabilities of embedded content. The allow-popups token specifically controls whether the iframe can open new browsing contexts. When absent, popups and window creation should be blocked.

In affected Electron builds, navigations taking the OpenURL path in Chromium's FrameLoader::StartNavigation did not consult the sandbox flags. An emulated user gesture, such as a scripted Ctrl+click, could reach the navigation pipeline and trigger window creation. The navigation would also invoke setWindowOpenHandler on the host WebContents, exposing application logic that assumed popup restrictions were enforced.

Root Cause

The root cause is a missing enforcement check in the navigation path. FrameLoader::StartNavigation did not verify the WebSandboxFlags::kPopups flag when the navigation policy differed from kNavigationPolicyCurrentTab and the triggering event was untrusted. This gap allowed sandboxed frames to bypass the popup restriction through emulated events.

Attack Vector

An attacker who controls content rendered inside a sandboxed iframe of an Electron application can script an untrusted event that dispatches a new-window navigation. No user interaction is required. If the host application depends on the sandbox to block popup creation and does not explicitly deny windows in setWindowOpenHandler, the attacker can force window creation or manipulate the handler's URL argument.

text
// Upstream Chromium patch: FrameLoader::StartNavigation enforces sandbox popup flag
// Source: https://github.com/electron/electron/commit/3ff23c52ab364a0afc6ab5bd7851291d3159de57
+  // A sandboxed iframe without `allow-popups` should not be able to
+  // open a new browsing context by emulating a user gesture in JS.
+  // (e.g. Ctrl+click).
+  if (request.GetNavigationPolicy() != kNavigationPolicyCurrentTab &&
+      request.GetTriggeringEventInfo() ==
+          mojom::blink::TriggeringEventInfo::kFromUntrustedEvent &&
+      frame_->GetSecurityContext()->IsSandboxed(
+          network::mojom::blink::WebSandboxFlags::kPopups)) {
+    return;
+  }

The corresponding Electron change in shell/browser/api/electron_api_web_contents.cc adds includes for web_sandbox_flags.h and enforces the flag along the OpenURL path. See GitHub Commit 57cbe32 for the full change.

Detection Methods for CVE-2026-70608

Indicators of Compromise

  • Unexpected calls into an application's setWindowOpenHandler originating from sandboxed iframes hosting third-party or untrusted content.
  • Creation of new BrowserWindow or child WebContents shortly after loading pages that embed untrusted iframes without allow-popups.
  • Renderer process logs showing navigation events with TriggeringEventInfo::kFromUntrustedEvent producing non-current-tab navigations.

Detection Strategies

  • Audit Electron application source for use of sandboxed iframes and confirm whether setWindowOpenHandler explicitly denies window creation for untrusted origins.
  • Inventory installed Electron-based desktop applications and compare their bundled Electron versions against 39.8.10, 41.10.3, and 42.0.1.
  • Enable Chromium logging in test environments and monitor FrameLoader::StartNavigation decisions when loading iframes without allow-popups.

Monitoring Recommendations

  • Track child process creation and window instantiation events tied to Electron parent processes on endpoints.
  • Correlate outbound network requests from Electron applications with unexpected new-window navigations to unknown hosts.
  • Alert on Electron application updates that lag behind the patched release lines.

How to Mitigate CVE-2026-70608

Immediate Actions Required

  • Upgrade Electron to 39.8.10, 41.10.3, or 42.0.1 and rebuild affected applications.
  • Review all setWindowOpenHandler implementations and default to denying window creation for untrusted origins.
  • Reassess whether untrusted content must be embedded in sandboxed iframes, and isolate such content in separate WebContents where feasible.

Patch Information

The issue is fixed in Electron v39.8.10, v41.10.3, and v42.0.1. The upstream fix respects iframe sandbox flags on the OpenURL navigation path and is tracked in GHSA-9f4c-93c8-jc8g, PR #51437, PR #51438, and PR #51439.

Workarounds

  • Implement a setWindowOpenHandler that returns { action: 'deny' } by default and only allow specific, vetted URLs.
  • Avoid rendering untrusted third-party content inside sandboxed iframes; use isolated <webview> tags or separate BrowserWindow instances with strict webPreferences.
  • Apply a strict Content Security Policy (frame-src, child-src) to restrict where iframes can load content.
bash
# Example: deny-by-default window open handler in the main process
const { app, BrowserWindow } = require('electron')

app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: { sandbox: true, contextIsolation: true }
  })

  win.webContents.setWindowOpenHandler(({ url }) => {
    const allowed = ['https://trusted.example.com/']
    if (allowed.some(prefix => url.startsWith(prefix))) {
      return { action: 'allow' }
    }
    return { action: 'deny' }
  })
})

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.