CVE-2026-34768
Electronjs Electron ≤ 38.8.6
Raw vector
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:LSummary
CVE-2026-34768 is a low-severity Unquoted Search Path or Element (CWE-428) vulnerability in Electronjs Electron. Its CVSS base score is 3.9 (Low).
Operationally, exploitation aligns with the MITRE ATT&CK technique Path Interception (T1034); ranked at the 3th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34768 is a vulnerability in the Electron framework, which enables development of cross-platform desktop applications using JavaScript, HTML, and CSS. On Windows systems, versions prior to 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8 improperly handle the `app.setLoginItemSettings({openAtLogin: true})` function by writing the application's executable path to the Run registry key without proper quoting. This issue, classified under CWE-428 (Unquoted Search Path or Element), affects applications that enable auto-start at login when installed in paths containing spaces.
Exploitation requires a local attacker with high privileges (PR:H) and write access to an ancestor directory of the application's installation path. On default Windows installations, standard system directories are protected from writes by standard users, limiting feasibility to non-standard installation locations. Successful exploitation allows the attacker to substitute a malicious executable that runs at user login instead of the intended application, potentially leading to limited confidentiality, integrity, and availability impacts as scored by CVSS 3.9 (AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L).
The Electron security advisory at https://github.com/electron/electron/security/advisories/GHSA-jfqx-fxh3-c62j confirms the issue has been patched in versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8, recommending immediate upgrades for affected applications to mitigate the unquoted path risk.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-18935
Vulnerability Data
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8, on Windows, app.setLoginItemSettings({openAtLogin: true}) wrote the executable path to the Run registry key without quoting. If the app…
more
is installed to a path containing spaces, an attacker with write access to an ancestor directory may be able to cause a different executable to run at login instead of the intended app. On a default Windows install, standard system directories are protected against writes by standard users, so exploitation typically requires a non-standard install location. This issue has been patched in versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover unquoted search paths through static analysis or dynamic test cases.
Documented development standards and tools can mandate proper quoting and escaping of path elements.
Engineering principles can require safe construction and quoting of search paths and command elements.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent path-handling flaws such as unquoted elements during development.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect unquoted search-path issues before deployment.
Enforcing controlled software installation can prevent unquoted search-path elements in executables and scripts.
Secure development lifecycle practices include input validation and path handling that reduce unquoted search-path weaknesses.
Secure system architecture and engineering principles require safe path construction and quoting conventions.
Secure coding standards directly mandate quoting search paths and avoiding unsafe path construction.
Change-management processes can enforce review of path-handling changes that might introduce unquoted elements.