CVE-2026-70612: Electron Privilege Escalation Vulnerability

CVE-2026-70612 Overview

CVE-2026-70612 is an access control weakness [CWE-284] in the Electron framework, which is used to build cross-platform desktop applications with JavaScript, HTML, and CSS. Requests to open external protocol URLs from web content did not honor iframe sandbox restrictions. A sandboxed iframe rendering untrusted content could therefore trigger the launch of an OS-registered external application. The frame sandbox state was also not passed to app permission handlers, so applications relying on the default openExternal permission behavior were exposed. Electron patched the issue in versions 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3.

Critical Impact
Sandboxed iframes rendering untrusted content can bypass sandbox restrictions to launch external OS applications through registered protocol handlers.

Affected Products

Electron versions prior to 39.8.8
Electron 40.x versions prior to 40.9.0
Electron 41.x versions prior to 41.2.1 and 42.x versions prior to 42.0.0-beta.3

Discovery Timeline

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

Technical Details for CVE-2026-70612

Vulnerability Analysis

Electron exposes the shell.openExternal API and browser-initiated external protocol navigations to allow apps to launch OS-registered handlers such as mailto:, tel:, or custom application URI schemes. The vulnerability stems from the external protocol dispatch path ignoring the sandbox flags of the initiating frame. When a sandboxed iframe issued a navigation to an external protocol URL, the request reached the OS handler without any check against the frame's sandbox state.

Applications that render untrusted third-party content in sandboxed iframes were most affected. If no setPermissionRequestHandler was installed, the default permission handler granted openExternal requests without visibility into whether the request originated from a sandboxed frame. Attackers could abuse this to trigger arbitrary registered protocol handlers, potentially delivering arguments to native applications and enabling secondary attacks against those handlers.

Root Cause

The ElectronBrowserClient code path handling external protocol navigation did not consume web_sandbox_flags.h values when deciding whether to dispatch the request. The frame's sandbox state was also not propagated to permission callbacks, breaking least-privilege enforcement.

Attack Vector

An attacker who controls content rendered inside a sandboxed iframe of a vulnerable Electron application can navigate to an external protocol URL. The Electron main process forwards the request to the OS handler despite the sandbox restrictions. The attack requires the target application to render attacker-controlled content in an iframe and to rely on default permission handling.

text

 // Patch excerpt: shell/browser/electron_browser_client.cc
 #include "services/network/public/cpp/resource_request_body.h"
 #include "services/network/public/cpp/self_deleting_url_loader_factory.h"
 #include "services/network/public/cpp/url_loader_factory_builder.h"
+#include "services/network/public/cpp/web_sandbox_flags.h"
 #include "shell/app/electron_crash_reporter_client.h"
 #include "shell/browser/api/electron_api_app.h"
 #include "shell/browser/api/electron_api_crash_reporter.h"

Source: Electron commit 08b9d0a2. The fix introduces web_sandbox_flags.h into the browser client so external protocol navigation respects iframe sandbox flags.

Detection Methods for CVE-2026-70612

Indicators of Compromise

Unexpected launches of OS-registered protocol handlers (for example, mailto:, ms-*:, custom URI schemes) originating from Electron application processes.
Child processes spawned by an Electron app immediately after rendering third-party iframe content.
Outbound navigation events in application logs to non-http(s) protocol schemes from sandboxed frame contexts.

Detection Strategies

Inventory installed Electron-based desktop applications and match versions against the fixed releases 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3.
Monitor process creation events where an Electron binary is the parent of a shell, browser, or protocol handler executable.
Review Electron application logs and browser process telemetry for openExternal calls tied to iframe origins that differ from the top-level document.

Monitoring Recommendations

Enable endpoint process-tree telemetry to correlate iframe-triggered protocol launches with the initiating Electron process.
Alert on Electron applications spawning uncommon URI handler binaries such as cmd.exe, powershell.exe, or scripting hosts.
Track software inventory changes to confirm Electron runtime upgrades across managed endpoints.

How to Mitigate CVE-2026-70612

Immediate Actions Required

Upgrade Electron to 39.8.8, 40.9.0, 41.2.1, or 42.0.0-beta.3 or later and rebuild dependent applications.
Audit application code for use of setPermissionRequestHandler and deny openExternal for sandboxed frames or untrusted origins.
Restrict the set of URL schemes that the application forwards to the OS via shell.openExternal.

Patch Information

The fix is tracked in GHSA-p2rr-rvmm-c5fp and shipped in Electron v39.8.8, v40.9.0, v41.2.1, and v42.0.0-beta.3. Corresponding pull requests are #50961, #50962, #50963, and #50964.

Workarounds

Install a custom setPermissionRequestHandler that inspects the requesting frame and denies openExternal from sandboxed or cross-origin iframes.
Avoid rendering untrusted web content inside Electron webContents or iframes until patched builds are deployed.
Maintain an allowlist of external URL schemes and validate URLs before calling shell.openExternal.

bash

# Example: deny openExternal for sandboxed iframes in the main process
session.defaultSession.setPermissionRequestHandler((webContents, permission, callback, details) => {
  if (permission === 'openExternal') {
    const isSandboxed = details && details.isSandboxed === true;
    return callback(!isSandboxed);
  }
  return callback(false);
});