Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

The software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.


Software has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems encompass a wide variety of issues -- all mitigated in very different ways and usually attempted in order to alter the control flow of the process. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities.


The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

This example code intends to take the name of a user and list the contents of that user's home directory. It is subject to the first variant of OS command injection.

$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName;

The $userName variable is not checked for malicious input. An attacker could set the $userName variable to an arbitrary OS command such as:

;rm -rf /

Which would result in $command being:

ls -l /home/;rm -rf /

Since the semi-colon is a command separator in Unix, the OS would first execute the ls command, then the rm command, deleting the entire file system.

Also note that this example code is vulnerable to Path Traversal (CWE-22) and Untrusted Search Path (CWE-426) attacks.

Example Two

Consider the following program. It intends to perform an "ls -l" on an input filename. The validate_name() subroutine performs validation on the input to make sure that only alphanumeric and "-" characters are allowed, which avoids path traversal (CWE-22) and OS command injection (CWE-78) weaknesses. Only filenames like "abc" or "d-e-f" are intended to be allowed.

my $arg = GetArgument("filename");

sub do_listing {

my($fname) = @_;
if (! validate_name($fname)) {

print "Error: name is not well-formed!\n";
# build command
my $cmd = "/bin/ls -l $fname";

sub validate_name {

my($name) = @_;
if ($name =~ /^[\w\-]+$/) {

else {


However, validate_name() alows filenames that begin with a "-". An adversary could supply a filename like "-aR", producing the "ls -l -aR" command (CWE-88), thereby getting a full recursive listing of the entire directory and all of its sub-directories.

There are a couple possible mitigations for this weakness. One would be to refactor the code to avoid using system() altogether, instead relying on internal functions.

Another option could be to add a "--" argument to the ls command, such as "ls -l --", so that any remaining arguments are treated as filenames, causing any leading "-" to be treated as part of a filename instead of another option.

Another fix might be to change the regular expression used in validate_name to force the first character of the filename to be a letter or number, such as:

if ($name =~ /^\w[\w\-]+$/) ...

See Also

OWASP Top Ten 2021 Category A03:2021 - Injection

Weaknesses in this category are related to the A03 category "Injection" in the OWASP Top Ten 2021.

Validate Inputs

Weaknesses in this category are related to the design and architecture of a system's input validation components. Frequently these deal with sanitizing, neutralizing a...

SFP Secondary Cluster: Tainted Input to Command

This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Command cluster (SFP24).

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses for Simplified Mapping of Published Vulnerabilities

CWE entries in this view (graph) may be used to categorize potential weaknesses within sources that handle public, third-party vulnerability information, such as the N...

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.

Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.