CVE-2026-112944 in launch-editor
Summary
by MITRE • 10/20/2026
launch-editor allows users to open files with line numbers in editor from Node.js. Prior to 2.14.2, when an attacker can create a filesystem entry beginning with plus or minus in the working directory, an affected editor is selected, and the path can remain relative or is converted to a relative WSL path, launchEditor forwards the path without forcing it to be interpreted as a positional filename. Editor option parsing then treats the attacker-controlled filename as a command-line flag, which can cause unintended file overwrite or arbitrary command execution by the selected editor. The affected editors are Vim and gVim, MacVim, Emacs and Emacsclient, and Notepad++ when a plugin exposes dangerous operations; WSL path conversion keeps Vite and newer middleware callers exposed. This issue is fixed in version 2.14.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The launch-editor library serves as a utility for Node.js applications to open specific files at designated line numbers within external text editors, facilitating developer workflows during debugging or code inspection. However, prior to the release of version 2.14.2, this functionality contained a critical command injection vulnerability stemming from improper handling of file paths that begin with plus or minus characters. This flaw arises because the library attempts to pass the filename and line number as arguments to external editor executables without sufficiently sanitizing or quoting the input path before it is processed by the target application's argument parser.
The technical root cause lies in how various editors interpret command-line arguments, specifically regarding positional parameters versus flags. When a file path starts with a plus sign (+) or a minus sign (-), many Unix-like tools and Windows applications treat these characters as indicators of option switches rather than literal filename components. In the context of launch-editor, if an attacker can control the working directory such that they create a filesystem entry starting with one of these special characters, the library forwards this path directly to the editor executable. Because the path is not forced into a format that explicitly denotes it as a positional argument, the target application's option parsing logic misinterprets the filename string as a command-line flag or switch.
This misinterpretation leads to severe operational impacts depending on which editor is invoked and its specific configuration. For editors such as Vim, gVim, MacVim, Emacs, and Emacsclient, an attacker can craft paths that exploit argument parsing quirks to cause unintended file overwrites or trigger arbitrary command execution through the editor's internal scripting capabilities. Similarly, Notepad++ remains vulnerable if it has plugins installed that expose dangerous operations accessible via command-line arguments. The vulnerability is further exacerbated in environments using Windows Subsystem for Linux (WSL), where path conversion logic may retain relative paths or WSL-specific formats that are susceptible to this injection vector, keeping middleware callers like Vite exposed to exploitation even after basic fixes might be applied elsewhere.
From a classification perspective, this issue aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-20 Improvement of Insufficient Input Validation. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Initial Execution through command injection techniques (T1059), allowing attackers to execute arbitrary code on a victim's system by leveraging trusted development tools that are often run with elevated privileges or access sensitive project files. The attack vector typically requires local file creation capabilities within the application's working directory, which may be achievable in scenarios where user-uploaded content is processed without strict sanitization of filenames.
To mitigate this vulnerability, organizations and developers must immediately upgrade to launch-editor version 2.14.2 or later, which implements proper argument separation and quoting mechanisms to ensure that file paths are treated strictly as positional parameters rather than executable flags. Additionally, defensive coding practices should be adopted by middleware consumers such as Vite; these include validating filenames against a whitelist of allowed characters before passing them to launch-editor and avoiding the use of relative paths when absolute paths can be securely resolved. Security teams should also audit their CI/CD pipelines and development environments for any custom scripts that invoke editors with unsanitized user-controlled input, ensuring that all external command invocations adhere to strict parameterization standards to prevent similar injection vectors in other tooling ecosystems.