Electron CVE-2026-70612

Exploitation requires two simultaneous conditions in the target Electron application: first, the application must render untrusted or attacker-influenced web content inside an HTML iframe element that carries sandbox restrictions (i.e., a sandboxed iframe); second, the application must not have installed a setPermissionRequestHandler, OR the installed handler must grant the openExternal permission for untrusted content - the default Electron behavior when no handler is configured grants this permission automatically. Apps that explicitly deny openExternal for untrusted sources in their permission handler are not exploitable. Additionally, the sandboxed iframe must not include the allow-top-navigation-to-custom-protocols, allow-top-navigation-by-user-activation (combined with user gesture), allow-top-navigation, or allow-popups tokens, because those tokens legitimately permit the navigation. What limits exploitation: the combination of sandbox-aware rendering plus absent permission hardening is a specific-but-default configuration; apps serving only trusted first-party content in iframes or apps with strict permission handlers are not at risk.

The NVD-assigned CVSS 3.1 score of 5.4 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:C reflects a realistic assessment. The Changed Scope (S:C) is significant: the vulnerability crosses process and OS boundaries to invoke an external application outside Electron's control, which could be leveraged to exploit vulnerabilities in the launched application or expose UX-level phishing surfaces (e.g., opening a mailto: handler to pre-fill a phishing email). The AC:H rating is justified because the attack requires two concurrent conditions: the Electron app must be rendering untrusted content inside sandboxed iframes AND must be running with the default openExternal permission (no setPermissionRequestHandler installed or handler that grants the permission). These are specific but not uncommon deployment patterns in Electron apps that act as web content browsers. No EPSS data was provided in the input, and the vulnerability is not listed in CISA KEV, so real-world exploitation probability cannot be quantified beyond what the CVSS signals indicate. There is no conflicting data between the CVSS vector and the description; both consistently indicate a network-delivered, unauthenticated attack against a specific configuration. The absence of a public POC and KEV listing reduces urgency somewhat, but Electron's broad deployment surface and the default-vulnerable configuration elevate practical priority for affected app developers.

An attacker hosts a malicious web page containing an iframe with only the allow-scripts sandbox token, embedding a child page that immediately navigates to a custom protocol URL such as magnet:// or a proprietary scheme. When an Electron application without a setPermissionRequestHandler loads this page, the iframe's navigation to the external protocol bypasses sandbox enforcement, prompting the OS to launch the registered handler - for example, a BitTorrent client, an email client with pre-filled fields, or a custom enterprise application - potentially exposing that application to attacker-controlled input. No public exploit code has been identified at time of analysis, but the attack logic is straightforward and closely mirrors the test cases included in the vendor patch.