What is the CVSS score of CVE-2026-70612?

CVE-2026-70612 has a CVSS 3.1 base score of 5.4 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N. EPSS exploitation probability: 0.4%.

Is there a public PoC exploit available for CVE-2026-70612?

Yes, a public proof-of-concept exploit is available for CVE-2026-70612. Prioritise patching immediately. EPSS: 0.4%.

Is there a patch available for CVE-2026-70612?

Yes, a patch is available for CVE-2026-70612. Update the affected software to the latest version immediately.

Electron CVE-2026-70612

EUVD-2026-53546 MEDIUM

Improper Access Control (CWE-284)

2026-08-05 https://github.com/electron/electron

GHSA-p2rr-rvmm-c5fp

Authentication Bypass

5.4

CVSS 3.1 · Vendor: https://github.com/electron/electron

Severity by source

Vendor (https://github.com/electron/electron) PRIMARY

5.4 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N

vuln.today AI

5.4 MEDIUM

Network-delivered, no auth required against default config; AC:H for dual prerequisite (sandboxed iframe + absent permission handler); S:C for OS-level handler launch crossing scope boundary; no availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N

4.0 AV:N/AC:H/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

High

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Aug 05, 2026 - 18:21 vuln.today

Analysis Generated

Aug 05, 2026 - 18:21 vuln.today

CVE Published

Aug 05, 2026 - 17:56 github-advisory

MEDIUM 5.4

DescriptionCVE.org

Impact

Requests to open external protocol URLs from web content did not take iframe sandbox restrictions into account, so a sandboxed iframe could cause an OS-registered external application to be launched. The frame's sandbox state was also not made available to the app's permission handlers.

Apps are only affected if they render untrusted content in sandboxed iframes and grant the openExternal permission (granted by default when no setPermissionRequestHandler is installed). Apps whose permission handler denies openExternal for untrusted content are not affected.

Workarounds

Install a setPermissionRequestHandler that denies the openExternal permission for untrusted content.

Fixed Versions

42.0.0-beta.3
41.2.1
40.9.0
39.8.8

For more information

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

AnalysisAI

External protocol handler bypass in Electron allows sandboxed iframes to launch OS-registered external applications, circumventing iframe sandbox enforcement in all Electron versions below 39.8.8, 40.9.0, 41.2.1, and 42.0.0-beta.3. The root cause is that Electron's HandleExternalProtocolInUI function in electron_browser_client.cc failed to inspect WebSandboxFlags before processing external protocol navigation requests, and critically did not forward the frame's sandbox state to the app's permission handler - so even a custom handler could not make an informed allow/deny decision. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, but the attack is network-deliverable with no authentication required against apps relying on Electron's default permission configuration.

Technical ContextAI

Electron (pkg:npm/electron) is a cross-platform desktop application framework that embeds Chromium and Node.js. The vulnerability resides in shell/browser/electron_browser_client.cc within the HandleExternalProtocolInUI function, which is invoked when web content attempts to navigate to a URL using a non-web protocol (e.g., magnet:, mailto:, custom:). The fix mirrors logic already present in Chromium (crbug.com/1148777): before allowing an external protocol launch from a sub-frame, the implementation must check network::mojom::WebSandboxFlags against the frame's active sandbox tokens. Prior to the fix, the sandbox_flags parameter was not passed to HandleExternalProtocolInUI at all, so the function treated sandboxed iframes identically to top-level frames. CWE-284 (Improper Access Control) accurately characterizes the root cause: an access control boundary - the HTML iframe sandbox - was not enforced on a specific code path. The sandbox tokens relevant to this check are allow-top-navigation-to-custom-protocols, allow-top-navigation-by-user-activation (with user gesture), allow-top-navigation, and allow-popups.

RemediationAI

The primary fix is to upgrade Electron to one of the patched releases: 39.8.8, 40.9.0, 41.2.1, or 42.0.0-beta.3, available at the respective GitHub release pages (https://github.com/electron/electron/releases/tag/v39.8.8, v40.9.0, v41.2.1, v42.0.0-beta.3). The patch backports Chromium's sandbox flag enforcement into HandleExternalProtocolInUI and ensures sandbox state is forwarded to permission handlers. For applications that cannot immediately upgrade, the documented workaround is to install a setPermissionRequestHandler that explicitly denies the openExternal permission for untrusted content - this is effective because it closes the permission gate regardless of whether sandbox flags are checked. The trade-off of the workaround is that legitimate openExternal navigations from untrusted iframes will also be blocked, which is the desired security posture. Applications that already have a permission handler denying openExternal for untrusted content are confirmed not affected by this vulnerability.