Official definition

The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.

When creating commands using interpolation into a string, developers may assume that only the arguments/options that they specify will be processed. This assumption may be even stronger when the programmer has encoded the command in a way that prevents separate commands from being provided maliciously, e.g. in the case of shell metacharacters. When constructing the command, the developer may use whitespace or other delimiters that are required to separate arguments when the command. However, if an attacker can provide an untrusted input that contains argument-separating delimiters, then the resulting command will have more arguments than intended by the developer. The attacker may then be able to change the behavior of the command. Depending on the functionality supported by the extraneous arguments, this may have security-relevant consequences.

Detailed description

When developers interpolate values into a command string, they may assume that preventing separate commands, such as by handling shell metacharacters, is sufficient. However, the receiving component may interpret argument delimiters in untrusted data as additional parameters. Those extra parameters can alter execution logic and, depending on the command’s supported functionality, may enable unauthorized code or command execution, reading or modification of data, or other unintended behavior.

Characteristics

This weakness occurs when command and data are combined in one string under the assumption that only developer-supplied arguments will be processed. Even if separate shell commands are blocked, untrusted data can contain argument delimiters, whitespace, quotation marks, or similar forms that introduce additional options or switches. The weakness is introduced during implementation and is not language- or technology-specific; the record identifies PHP as a frequently affected language.

Common consequences

An attacker may add arguments that execute unauthorized code or commands, alter execution logic, read application data, or modify application data. The record also associates the weakness with availability and other unintended effects, but does not define a more specific impact for those cases.

Impact	Scope	Explanation
Execute Unauthorized Code or Commands, Alter Execution Logic, Read Application Data, Modify Application Data	Confidentiality, Integrity, Availability, Other	An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.

Risk mitigations

Parameterize command construction: Avoid building one string containing the command and its arguments. Use APIs that accept independent arguments, such as an argument array, so quoting or escaping is handled appropriately. The record gives escapeshellarg with system and an argument array with exec in PHP, and refactoring from system to exec in C as examples.
Validate at defined interfaces: Identify untrusted data from parameters, cookies, networks, environment variables, headers, content, URLs, email, files, databases, and external systems. Assume input is malicious and use an accept-known-good allowlist that checks length, type, ranges, missing or extra values, syntax, consistency, and business rules. Do not rely only on denylists, though denylists can help detect attacks or reject clearly malformed input.
Normalize and type-check: Convert input directly to the expected type, then verify ranges and relationships among fields. Decode and canonicalize input into the application’s internal representation before validation, avoid double-decoding, and consider repeated canonicalization while recognizing that it can alter content that is legitimately encoded.
Preserve interface interpretation: Use the same character encoding across communicating components and explicitly set the encoding where the protocol permits. When combining data from multiple sources, validate the combined result, not only each individual element.
Test broadly: During testing, use fuzzing, robustness testing, and fault injection with large, diverse input suites. The product should not become unstable, crash, or produce incorrect results under these tests.

Parameterization · Implementation · Effectiveness: HighWhere possible, avoid building a single string that contains the command and its arguments. Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command. For example, in PHP, escapeshellarg() can be used to escape a single argument to system(), or exec() can be called with an array of arguments. In C, code can often be refactored from using system() - which accepts a single string - to using exec(), which requires separate function arguments for each parameter.
Input Validation · Architecture and DesignUnderstand all the potential areas where untrusted inputs can enter your product: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.
Input Validation · ImplementationAssume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
ImplementationDirectly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
ImplementationInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
ImplementationWhen exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
ImplementationWhen your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
TestingUse dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Detection methods

Automated static analysis, commonly called SAST, can find some instances by modeling data flow and control flow in source or compiled code, then searching for paths from input sources to sinks where data reaches an external component or a lower layer such as the operating system. The method is rated highly effective, but it does not guarantee complete coverage because it depends on the patterns and paths that the analysis can model.

Method	Approach	Effectiveness
Automated Static Analysis	Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)	High

Representative vulnerabilities

The following are representative examples, not an exhaustive list:

CVE-2022-36069: a Python dependency management tool prevented OS command injection when generating Git commands but allowed injection of optional arguments beginning with a hyphen, potentially enabling code execution.
CVE-1999-0113: the -froot argument was passed to another program, where -f caused execution as user root.
CVE-2001-0150, CVE-2001-0667, CVE-2004-0121, CVE-2004-0473, CVE-2004-0489, and CVE-2006-6597: browsers or URI-handling applications passed unintended command-line options to Telnet, mail clients, or other programs, potentially enabling command, program, or code execution.
CVE-2002-0985, CVE-2005-4699, and CVE-2016-10033: arguments were injected into mail or Whois functionality, allowing options to be changed and potentially enabling restriction bypass, sensitive information disclosure, file writing, or program execution.
CVE-2006-2312, CVE-2006-3015, and CVE-2004-0480: crafted URIs or pathnames changed program options, allowing file upload, file download, or use of an alternate configuration file.
CVE-2007-0882: a Telnet daemon interpreted certain -f sequences as valid requests to bypass authentication for the login program.
CVE-2019-13475: injection of the -exec option caused the command to be executed.
CVE-2006-1865, CVE-2006-2056, CVE-2006-2057, CVE-2006-2058, and CVE-2006-4692 are associated in the record with unsafe command construction or argument modification, although some entries do not clearly establish whether the specific cause was argument injection, shell metacharacters, an implementation issue, or an API problem.

Below are representative vulnerabilities related to this CWE, prioritized by severity.

Sources (2)

MITRE CWE

CWE Terms of Use

CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

What is CWE-88?

Vulnerabilities mapped to CWE-88

Vulnerabilities in CISA KEV for CWE-88

Official definition

Detailed description

Characteristics

Common consequences

Risk mitigations

Detection methods

Representative vulnerabilities

Supporting documents

Run an in-depth assessment with complete web risk management

Explore more resources from CyStack

Website security reports

CyStack research

Cybersecurity knowledge