CVE-2026-114121 in Electron
Summary
by MITRE • 10/21/2026
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, requests to open external protocol URLs could be attributed to a document other than the one that initiated them, causing the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content. An application that grants openExternal based on the requesting origin and allows untrusted content to open or navigate windows could therefore allow that content to launch an OS-registered external application. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
Electron serves as a foundational framework for developing cross-platform desktop applications by leveraging web technologies such as JavaScript, HTML, and CSS to create native-like user interfaces. Within this architecture, the handling of external protocol URLs is a critical security boundary that determines how an application interacts with the underlying operating system. Prior to specific patch releases including versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, Electron exhibited a significant logic flaw in its permission request handling mechanism. This vulnerability stems from an incorrect attribution of the origin associated with requests to open external protocol URLs, allowing untrusted content to masquerade as trusted content when triggering system-level actions.
The core technical flaw involves the misattribution of the requestingUrl parameter within the session.setPermissionRequestHandler API. When a web page or script initiates a request to launch an application via an external protocol such as mailto: or custom URI schemes, Electron is designed to pass the origin of the document that initiated the action to the permission handler. This allows developers to implement security policies based on trust levels assigned to specific origins. However, in vulnerable versions, this attribution mechanism fails under certain conditions where untrusted content can cause requests to be attributed to a different, trusted document than the one actually initiating them. Consequently, if an application grants openExternal permissions based solely on the requesting origin without additional verification of the actual initiator, it may inadvertently allow malicious or untrusted web content to trigger OS-registered external applications.
This vulnerability aligns with CWE Category 20 Improper Input Validation and specifically relates to CWE 918 Server-Side Request Forgery (SSRF) variants where trust boundaries are bypassed through origin confusion. From an ATT&CK perspective, this flaw facilitates lateral movement or execution of unauthorized programs by allowing attackers who control untrusted web content within the Electron application to execute arbitrary system commands or launch applications that may contain further vulnerabilities. The operational impact is severe for any Electron-based desktop application that relies on origin-based permission checks to secure external protocol launches. An attacker could exploit this by embedding malicious scripts in a trusted context, such as an iframe from a different domain, which then triggers the opening of sensitive system utilities or network-connected applications without proper user consent or security validation.
The mitigation for this issue requires immediate upgrading to patched versions of Electron that correct the attribution logic for external protocol requests. Developers must also review their implementation of session.setPermissionRequestHandler to ensure that permission grants are not solely dependent on the requestingUrl origin, as this field can now be reliably trusted but should still be part of a defense-in-depth strategy. It is advisable to implement additional checks such as verifying user interaction signals or using allowlist approaches for specific protocols rather than broad trust based on document origin alone. By addressing this flaw and updating dependencies, organizations can prevent unauthorized execution of external applications and maintain the integrity of their desktop application security posture against web-based attack vectors.