Electron applications use app.setAsDefaultProtocolClient to register custom protocols. In versions before 38.8.6, 39.8.1, 40.8.1, and 41.0.0 on Windows, the function fails to validate the protocol argument, allowing a user‑supplied string that can be interpreted as a registry path. This flaw combines input validation errors (CWE‑20), path traversal (CWE‑74), and an unchecked heap allocation (CWE‑791). An attacker who can influence the protocol name sent to the call can write to arbitrary subkeys under HKCU\Software\Classes, potentially hijacking existing protocol handlers and redirecting traffic to malicious executables.

All Electron-based desktop applications running on Windows that invoke app.setAsDefaultProtocolClient with a protocol name derived from external or otherwise untrusted input are affected. The issue is present only in Electron versions prior to 38.8.6, 39.8.1, 40.8.1, and 41.0.0; applications that use hard‑coded protocol names are not vulnerable. The vulnerability is specific to the Windows platform where protocol registration occurs via the registry.

The CVSS score of 4.7 reflects moderate severity, and an EPSS probability of less than 1% indicates low likelihood of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog, further suggesting that active exploitation is currently uncommon. Exploitation requires an attacker to supply untrusted data to an Electron app’s setAsDefaultProtocolClient call, so the attack vector is local or user‑initiated. Although the flaw does not provide arbitrary code execution, it enables protocol hijacking that could lead to phishing or malware delivery when combined with social engineering or other attacks.