CVE-2026-100368: OS Command Injection in CliInvoke Shell Wrappers

The CliInvoke.Specializations package provides specialized wrappers to execute external targets using shell interpreters such as Windows Command Prompt (cmd.exe) and PowerShell (powershell.exe/pwsh). These wrappers are implemented through components like PowershellProcessInvoker, CmdProcessInvoker, and middleware components like UsePowerShell and UseCmd in v3 pre-releases. Their design simplifies executing utilities in a shell-managed environment but expands the system attack surface when untrusted inputs are passed as parameters.

The primary exposure vector occurs when user-controlled data is passed as either the executable target path or the command arguments to these wrappers. In vulnerable versions, the library attempts to concatenate these parameters into a unified command string. The core vulnerability is categorized as CWE-78 (OS Command Injection) because the input escaping and validation logic fails to neutralize the semantic impact of double quotes (").

Process creation on Windows environments using the standard .NET System.Diagnostics.Process library eventually interacts with the Win32 CreateProcessW API. Unlike Unix-like environments that natively execute programs via array-based execve calls, Windows processes take command line parameters as a single, serialized Unicode string. When an application passes arguments using the legacy ProcessStartInfo.Arguments property, the .NET runtime passes this string directly to the target executable.

In vulnerable configurations of CliInvoke.Specializations, the library consolidated the path of the target and its arguments into one flat string. The library then applied custom character-escaping operations, such as adding the Windows command prompt escape caret (^) or the PowerShell backtick (`) to suspect metacharacters. This sanitization strategy incorrectly assumed that the shell interpreter would process the string first.

However, because the command line is passed as a flat string to the operating system, Windows executes its internal tokenization routine (typically matching CommandLineToArgvW rules) to find the program boundary before loading the shell interpreter (cmd.exe or pwsh.exe). If the input contains a double quote ("), it pairs with other quotes in the constructed command line to invert or break the outer quoting context. This splits the single argument into multiple distinct OS-level arguments, allowing attackers to introduce shell control operators that bypass the library's custom escape functions.

In the vulnerable codebase, RunnerProcessFactory.cs managed the wrapping logic by formatting commands directly into combinedArgs using basic string operations and specialized escaping helpers.

// VULNERABLE CODE BLOCK
// The target and arguments were escaped and formatted into a single string.
string safeTarget = ShellArgumentEscaper.EscapeForCmd(processConfigToBeRun.TargetFilePath);
string safeArguments = ShellArgumentEscaper.EscapeForCmd(processConfigToBeRun.Arguments);
combinedArgs = $\"{prefix} \\\"{safeTarget}\\\" {suffix}\".Trim();

This approach allowed a single double-quote inside processConfigToBeRun.Arguments to close the surrounding quote block prematurely. The patched version resolved this by switching completely to structured token arrays. Instead of passing strings to ProcessStartInfo.Arguments, the system splits the arguments programmatically using a newly introduced ArgumentTokenizer class and delivers them to the process using the ProcessStartInfo.ArgumentList collection.

// PATCHED CODE BLOCK (ArgumentTokenizer.cs - Commit 1e98582f02eb43e345e5b97b8dd6ff9443806685)
// Splits the command-line argument string into discrete tokens.
internal static class ArgumentTokenizer
{
    internal static IReadOnlyList<string> Tokenize(string? value)
    {
        if (string.IsNullOrWhiteSpace(value))
            return [];
 
        string text = value!;
        List<string> tokens = new();
        StringBuilder current = new();
        bool inQuotes = false;
 
        for (int i = 0; i < text.Length; i++)
        {
            char c = text[i];
            if (c == '"')
            {
                if (inQuotes && i + 1 < text.Length && text[i + 1] == '"')
                {
                    current.Append('"');
                    i++;
                    continue;
                }
                inQuotes = !inQuotes;
                continue;
            }
            if (!inQuotes && char.IsWhiteSpace(c))
            {
                if (current.Length > 0)
                {
                    tokens.Add(current.ToString());
                    current.Clear();
                }
                continue;
            }
            current.Append(c);
        }
        if (current.Length > 0)
            tokens.Add(current.ToString());
 
        return tokens;
    }
}

The patch for CmdMiddleware.cs and PowerShellMiddleware.cs (Commit 2077e5239850e83dc9cc67ae6036dcd4e68a1876) builds on this tokenization strategy. By defining the middleware target commands within an immutable argumentList array instead of compiling a flat arguments string, the operating system's command line tokenizer treats each item as a static argument, preventing any nested parameter from breaking out of its parsing boundaries.

To exploit the vulnerability, an attacker must identify an entry point where the application accepts user input and subsequently processes it through one of the affected CliInvoke.Specializations shell wrappers. This usually happens in administration portals, automation scripts, or file-processing functions where target binaries or arguments are dynamically defined. The attacker does not need any system privilege other than the ability to trigger the underlying command-execution function.

When targeting the Command Prompt wrapper (CmdProcessInvoker or UseCmd middleware), the attacker can inject a payload that closes the double quote wrapping the argument list and then appends an ampersand (&) command separator. For example, injecting the string arg" & calc.exe & " causes the library to format the command string as cmd.exe /c "target.exe arg" & calc.exe & "". The Windows command-line parser tokenizes this into multiple commands, and cmd.exe executes the malicious payload immediately after target.exe.

When targeting the PowerShell wrapper, a similar escape payload can be crafted. By supplying a target value of prog" & calc.exe & ", the generated arguments parameter resolves to pwsh.exe -NoProfile -NonInteractive -Command & "prog" & calc.exe & "". Because PowerShell treats the ampersand as the call operator or statement separator depending on context, it interprets the broken sequence as independent script blocks, triggering arbitrary code execution inside the PowerShell runtime environment.

The security impact of CVE-2026-100368 is classified as High, with a CVSS v3.1 base score of 8.4. Because the injected commands are spawned directly by the underlying .NET application process, the payload inherits the exact privilege level, security token context, and network access rights of the host application. If the host application runs with elevated service privileges (such as LocalSystem or NetworkService), the exploit results in full compromise of the hosting operating system.

Attackers can exploit this vector to perform unauthorized local operations, including reading sensitive configuration files, modifying application data, or establishing persistent backdoors. Although the vulnerability requires local placement of the exploit vector (resulting in a Local L Attack Vector score), web-facing applications that expose input forms or API endpoints that eventually invoke these shell wrappers will allow remote, unauthenticated command execution over the network.

At the time of this analysis, there are no records of this vulnerability being actively exploited in wild campaigns, nor is it listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. However, because command injection vulnerabilities are highly sought after by threat actors, any systems utilizing the vulnerable libraries should be treated as high priority for patching, especially if they handle untrusted user arguments or file names.

The primary remediation strategy is upgrading all CliInvoke.Specializations packages to a patched release. For environments using the 2.10.x branch, upgrade to version 2.10.5 or later. For environments on the 2.9.x branch, upgrade to 2.9.4 or later, and for 2.8.x, upgrade to 2.8.5 or later. Pre-release applications running the 3.x alpha builds must update to version 3.0.0-beta.1 or later. Legacy installations under the package name AlastairLundy.CliInvoke.Specializations must upgrade to version 2.0.2 or later.

If immediate patching is not possible, developers should implement input validation filters to sanitize all inputs before they reach the shell wrappers. The validation logic must explicitly reject any input containing double quotes ("). For older package versions between 2.2.0 and 2.9.2, the input validation must also reject critical shell metacharacters, including semicolons (;), pipe characters (|), ampersands (&), dollar signs ($), backticks (`), and parentheses ((, )).

Additionally, security teams should evaluate the architecture to determine if the shell wrappers can be bypassed entirely. Directly invoking target binaries via ProcessStartInfo without invoking an intermediate shell interpreter like cmd.exe or powershell.exe removes the shell-parsing layer from the execution chain, eliminating the command injection threat surface entirely.