Electron EUVD-2026-53436

Three conditions must all be true simultaneously: (1) the Electron application must accept file path input derived from an untrusted or attacker-influenced source - this includes renderer-to-main IPC, protocol handlers, CLI arguments, or any externally supplied string used as a path; (2) the application must validate the path using JavaScript string operations only (e.g., path.endsWith('.pdf'), /\.txt$/.test(path)) without making any Node.js fs API call (fs.existsSync, fs.stat, fs.access, fs.realpath) on that path before passing it to shell.openPath() - apps that call any fs method are not affected because Node already rejects null-byte paths at that layer; and (3) the attacker must be able to inject a null byte into the path string reaching the application. Additionally, CVSS UI:R indicates user interaction is required to trigger the file-open action, limiting automated or fully silent exploitation. The combination of AC:H and these three specific preconditions means the vast majority of Electron applications - those that either do not use shell.openPath() with untrusted input, or that perform any fs-level check - are not affected.

The CVSS 3.1 score of 6.0 accurately reflects a constrained attack surface: AV:L confines exploitation to the local context of a running Electron application, AC:H requires a specific and relatively uncommon application code pattern (untrusted input + string-only validation + shell.openPath()), PR:L requires the attacker to have some level of access to supply crafted input, and UI:R means a user action (e.g., opening a file) must trigger the vulnerable path. The C:H/I:H impact metrics are realistic - arbitrary file execution or exposure is the outcome - but the conditions required to reach that impact are narrow. No EPSS score is present in the source data, preventing quantitative exploitation probability assessment; this absence should be noted by security teams. No CISA KEV listing and no public POC code are confirmed, indicating this is not actively exploited at scale. Real-world risk is primarily relevant to Electron apps in environments where attackers can influence file path inputs - for example, apps that handle user-supplied URLs, IPC messages from web content, or file paths from external data sources - and where developers have relied solely on string-based path validation rather than filesystem-level checks.

An attacker who can supply a crafted file path to a vulnerable Electron application - for instance, via an IPC message from a renderer process, a URI handler, a CLI argument, or an application-level file picker that accepts external input - provides a path such as '/safe/uploads/report.pdf\0/tmp/malware.exe'. The application's string-based validation checks the extension, finds '.pdf', and passes the path to shell.openPath(); the OS runtime interprets the string up to the null byte, resolving to '/tmp/malware.exe' and launching the attacker's payload in the user's desktop context. No public exploit code is known at time of analysis, but null-byte injection as a technique is well-documented and the exploitation concept is straightforward for developers familiar with the pattern.