CVE-2026-100369: Argument Injection Vulnerability in CliInvoke Process Runner Factories

The .NET libraries CliInvoke and AlastairLundy.CliInvoke are designed to invoke command-line programs and wrap executable processes. They provide abstraction layers for process management, configuration, and invocation. The attack surface of these libraries is exposed when applications take untrusted, user-controlled input and pass it directly to executable process configurations.\n\nThe primary flaw is classified under CWE-88 (Improper Neutralization of Argument Delimiters in a Command). The runner factories fail to adequately neutralize double-quote characters when assembling a combined argument string. This design allows local attackers to manipulate the parameters of downstream process executions, potentially achieving arbitrary system command execution.

Prior to the security patch, RunnerProcessFactory (in the 2.x release branch) and RunnerConfigurationFactory (in the 3.x release branch) dynamically combined runner configurations with target process parameters. The library consolidated the runner arguments, target file path, and target process arguments into a single string using string interpolation.\n\nThis interpolated string was then directly assigned to the ProcessStartInfo.Arguments property. While the library leveraged escaping utilities like ShellArgumentEscaper.EscapeForCmd or ShellArgumentEscaper.EscapeForPowerShell, the escaping model relied on the operating system's command parser to split the single argument string back into an argument vector. This process failed when the input path or arguments contained double quotes.\n\nInjecting a double quote (") into the target executable path or its associated arguments terminates the quoted region at the operating-system level. The parser treats subsequent characters as separate parameters or script elements rather than part of the intended path or argument. This allows for command execution under wrapper configurations.

The original vulnerable code path performed straightforward string interpolation to build the parameters. The target execution properties were merged directly:\n\ncsharp\n// Vulnerable interpolated construction\nstring combinedArgs = $"{runnerProcessConfig.Arguments} {processConfigToBeRun.TargetFilePath} {processConfigToBeRun.Arguments}".Trim();\nprocessStartInfo.Arguments = combinedArgs;\n\n\nThe patch remediates this injection vector by discarding raw string concatenation. The fix implements an internal state-machine tokenizer (ArgumentTokenizer) to tokenize argument strings into discrete, independent entries. This allows the libraries to securely isolate user input.\n\ncsharp\n// ArgumentTokenizer tokenizing loop\nfor (int i = 0; i < text.Length; i++) {\n char c = text[i];\n if (c == '"') {\n if (inQuotes && i + 1 < text.Length && text[i + 1] == '"') {\n current.Append('"');\n i++;\n continue;\n }\n inQuotes = !inQuotes;\n continue;\n }\n if (!inQuotes && char.IsWhiteSpace(c)) {\n if (current.Length > 0) {\n tokens.Add(current.ToString());\n current.Clear();\n }\n continue;\n }\n current.Append(c);\n}\n\n\nIn addition to tokenization, the patch transitions to utilizing the native .NET structured invocation mechanism. On platforms running .NET 8.0 or greater, the library populates the native ProcessStartInfo.ArgumentList collection instead of writing to the single .Arguments string property. This structured API ensures the operating system handles quote escaping safely and isolates each token from the command shell's parsing engine.

An attacker can exploit this vulnerability if they control the parameters parsed by the runner process factory. For example, if a target application executes commands through a shell runner such as PowerShell (pwsh.exe -Command), the attacker can supply a crafted file path to trigger the execution breakout.\n\nA conceptual payload targeting a PowerShell runner utilizes double quotes to terminate the path argument. The attacker configures the target file path to: app"evil.exe. The vulnerable library compiles this configuration into the following single string:\n\npowershell\npwsh.exe -NoProfile -Command & "app"evil.exe" safe\n\n\nWhen the PowerShell shell parser reads this command line, it interprets & "app" as a complete command token. The subsequent characters (evil.exe) are interpreted as a distinct, new executable token. This causes the shell interpreter to run the injected executable (evil.exe) instead of passing it as a sub-argument, resulting in unauthorized command execution.

The impact of this vulnerability depends on the permissions of the parent application calling CliInvoke. Successful exploitation results in arbitrary local command execution with the privileges of the active .NET process. This can lead to local privilege escalation, unauthorized system configuration changes, and data exfiltration if the parent process has high system privileges.\n\nThe CVSS v3.1 score of 8.4 reflects the high severity of the vulnerability. The low attack complexity and the lack of user interaction requirements increase the likelihood of success if an application processes untrusted command arguments. However, because it is an argument injection flaw targeting a local utility library, the attack vector is classified as Local (AV:L), which mitigates broader remote exploitation unless a remote interface passes input directly to the library.

The primary remediation strategy is upgrading all dependent packages to their patched versions. For the CliInvoke NuGet package, users must upgrade to version 2.8.5, 2.9.4, 2.10.5, or 3.0.0-beta.2 (or later). For the legacy AlastairLundy.CliInvoke package, users must upgrade to version 2.0.2.\n\nDevelopers should target .NET 8.0 or newer runtimes for their compiled applications. Targeting .NET 8.0 enables the library's adapter layer to map configurations directly to ProcessStartInfo.ArgumentList, fully neutralizing string-parsing breakout vectors.\n\nIf upgrading is not immediately feasible, developers can mitigate the flaw by implementing input sanitization. This involves filtering out double-quote characters from target paths and arguments before passing them to the factories. Additionally, developers can manually construct target configurations by bypassing the vulnerable factory and populating the process parameters through explicit token lists.