CVE-2026-100368 in CliInvoke.Specializations
Summary
by MITRE • 09/25/2026
CliInvoke is a .NET library for invoking command-line programs, and its `CliInvoke.Specializations` packages provide specialized wrappers for shells such as PowerShell and Windows Command Prompt. `CliInvoke.Specializations` versions 2.2.0 through 2.8.4, 2.9.0 through 2.9.3, 2.10.0 through 2.10.4, 3.0.0-alpha.1 through 3.0.0-alpha.4, and 3.0.0-alpha.8 through 3.0.0-alpha.10, as well as `AlastairLundy.CliInvoke.Specializations` versions 1.0.0-rc.1 through 1.6.1.1, contain an OS command injection vulnerability in their PowerShell and Cmd wrappers. The wrappers pass a caller-controlled target and arguments to `pwsh -Command` or `cmd /c` using a single `ProcessStartInfo.Arguments` string, allowing a double quote in untrusted input to break operating-system-level quoting and cause the shell to execute an additional command with the host process's privileges. The vulnerability is patched in `CliInvoke.Specializations` versions 2.8.5, 2.9.4, 2.10.5, and 3.0.0-beta.1, and in `AlastairLundy.CliInvoke.Specializations` version 2.0.2. No complete workaround is available; users unable to upgrade should reject or remove double quotes from target paths and arguments, additionally reject shell metacharacters in versions 2.2.0 through 2.9.2 and 3.0.0-alpha.1 through 3.0.0-alpha.4, or bypass the PowerShell and Cmd wrappers and invoke target processes directly when handling untrusted input.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in CliInvoke.Specializations represents a critical OS command injection flaw affecting multiple versions of this .NET library designed for invoking command-line programs. The affected software includes specific version ranges such as 2.2.0 through 2.8.4, 2.9.0 through 2.9.3, and various alpha releases up to 3.0.0-alpha.10, alongside the AlastairLundy.CliInvoke.Specializations package versions from 1.0.0-rc.1 to 1.6.1.1. This library provides specialized wrappers for interacting with shells like PowerShell and Windows Command Prompt, which are commonly used in automated scripts and administrative tools. The core issue lies within the implementation of these shell-specific wrappers, where the design fails to adequately sanitize or escape user-supplied input before passing it to the underlying operating system command interpreter.
The technical root cause is a failure to properly handle special characters, specifically double quotes, when constructing the arguments string for ProcessStartInfo. When the library passes caller-controlled target paths and arguments to commands such as pwsh -Command or cmd /c, it relies on a single argument string without robust escaping mechanisms. If an attacker can inject a double quote into untrusted input, they can break out of the intended command context. This breaks operating-system-level quoting rules, allowing the shell to interpret subsequent characters not as part of the original command but as new, distinct commands. Consequently, this enables arbitrary code execution with the privileges of the host process running the application that utilizes the vulnerable library version.
From a security classification perspective, this vulnerability aligns closely with CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The attack vector allows for remote or local exploitation depending on where the untrusted input originates, potentially leading to full system compromise if the host process runs with elevated privileges such as Administrator rights. In terms of tactical mapping, this behavior corresponds to ATT&CK technique T1059 Command and Scripting Interpreter, specifically leveraging sub-components like PowerShell or Windows CMD for execution. The ability to inject commands via argument manipulation is a classic pattern in command injection attacks where input validation is insufficient against shell metacharacters that alter the parsing logic of the interpreter.
The operational impact of this vulnerability can be severe, ranging from unauthorized data access and modification to complete system takeover. Since the injected commands execute with the same privileges as the vulnerable application, an attacker could potentially escalate privileges if the application runs with high-level permissions. This is particularly dangerous in enterprise environments where such libraries are used for deployment scripts, configuration management tools, or automated maintenance tasks that often require administrative access. The lack of a complete workaround means that simply filtering certain inputs may not be sufficient; attackers might use alternative metacharacters or encoding techniques to bypass basic filters if the underlying mechanism remains flawed.
Mitigation strategies primarily involve upgrading to patched versions immediately. For CliInvoke.Specializations, this includes version 2.8.5 and later within the 2.x series, version 2.9.4 for the 2.9 line, version 2.10.5 for the 2.10 line, and version 3.0.0-beta.1 or newer for the 3.x alpha releases. For users of AlastairLundy.CliInvoke.Specializations, upgrading to version 2.0.2 is required. If immediate upgrade is not feasible due to dependency constraints, developers must implement strict input validation as a temporary defense-in-depth measure. This involves rejecting any target paths or arguments containing double quotes entirely. Furthermore, for older versions such as those between 2.2.0 and 2.9.2, it is critical to reject all shell metacharacters including semicolons, pipes, ampersands, and redirection operators in addition to quotes.
An alternative mitigation approach involves bypassing the specialized PowerShell and Cmd wrappers altogether when handling untrusted input. Instead of using CliInvoke.Specializations for these specific shells, developers should invoke target processes directly using standard ProcessStartInfo configurations with separate argument arrays rather than a single concatenated string. This native .NET approach avoids passing commands through an intermediate shell interpreter entirely, thereby eliminating the vector for command injection via shell metacharacters. While this requires code refactoring, it provides a more secure foundation for executing external programs when dealing with data that cannot be fully trusted or sanitized to meet the strict requirements of safe shell invocation.