The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.

What CVEs are caused by CWE-77?

3,150 recorded CVEs are attributed to CWE-77, including CVE-2025-10035, CVE-2024-55956, CVE-2005-2773. 34 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Is CWE-77 part of the OWASP Top 10?

CWE-77 maps to OWASP Top Ten 2007: Injection Flaws (A2) in the OWASP security taxonomy.

What are the consequences of CWE-77?

Exploiting CWE-77 can lead to: Execute Unauthorized Code or Commands.

Is CWE-77 actively exploited?

Yes. 34 CWE-77 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 3,150 recorded CVEs.

CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')

Overview

Many protocols and products have their own custom command language. While OS or shell command strings are frequently discovered and targeted, developers may not realize that these other command languages might also be vulnerable to attacks.

Real-world CVEs

3,150 recorded CVEs are caused by CWE-77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')), including 34 in CISA's KEV (Known Exploited Vulnerabilities) catalog. KEVs are shown first. 693 new CWE-77 CVEs have been recorded so far in 2026 (589 in 2025).

Showing 12 of 3,150 recorded CWE-77 CVEs. Get an alert for each new one, with AI-written analysis and fixes.

Monitor CWE-77 vulnerabilities

Common consequences

What can happen when CWE-77 is exploited.

Execute Unauthorized Code or Commands

Affects: Integrity, Confidentiality, Availability

If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed. This gives an attacker a privilege or capability that they would not otherwise have.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Applies to

Technologies

AI/ML

How to prevent it

Practical mitigations for CWE-77, grouped by where in the lifecycle they apply.

Architecture and Design

If at all possible, use library calls rather than external processes to recreate the desired functionality.

Implementation

If possible, ensure that all external commands called from the program are statically created.

Implementation

Input Validation

Assume 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.

Operation

Run time: Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands.

System Configuration

Assign permissions that prevent the user from accessing/opening privileged files.

How to detect it

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.)

Effectiveness: High

Code examples

MITRE examples of the weakness in code.

Consider a "CWE Differentiator" application that uses an an LLM generative AI based "chatbot" to explain the difference between two weaknesses. As input, it accepts two CWE IDs, constructs a prompt string, sends the prompt to the chatbot, and prints the results. The prompt string effectively acts as a command to the chatbot component. Assume that invokeChatbot() calls the chatbot and returns the response as a string; the implementation details are not important here.

Vulnerable example

python

prompt = "Explain the difference between {} and {}".format(arg1, arg2)

Example

plaintext

Explain the difference between CWE-77 and CWE-78

Attack input

plaintext

Arg1 = CWE-77

Resulting query

plaintext

Explain the difference between CWE-77 and CWE-78.

Safe example

python

cweRegex = re.compile("^CWE-\d+$")

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.

Vulnerable example

perl

my $arg = GetArgument("filename");

Safe example

perl

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

However, validate_name() allows 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:

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

Vulnerable example

c

int main(int argc, char** argv) {

The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.

The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Illustrative examples

Real CVEs that MITRE cites as examples of this weakness.

CVE-2020-9054
CISA KEV
— Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
CVE-2022-1509 — injection of sed script syntax ("sed injection")
CVE-2024-5184 — API service using a large generative AI model allows direct prompt injection to leak hard-coded system prompts or execute other prompts.
CVE-2020-11698 — anti-spam product allows injection of SNMP commands into confiuration file
CVE-2019-12921 — image program allows injection of commands in "Magick Vector Graphics (MVG)" language.
CVE-2022-36069 — Python-based dependency management tool avoids OS command injection when generating Git commands but allows injection of optional arguments with input beginning with a dash (CWE-88), potentially allowing for code execution.
CVE-1999-0067 — Canonical example of OS command injection. CGI program does not neutralize "|" metacharacter when invoking a phonebook program.
CVE-2021-41282 — injection of sed script syntax ("sed injection")
CVE-2019-13398 — injection of sed script syntax ("sed injection")

Parent, child, and peer weaknesses in the CWE hierarchy.

Parent

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

Child

Terminology & mappings

Alternate terms

Command injection: an attack-oriented phrase for this weakness. Note: often used when "OS command injection" (CWE-78) was intended.

Mapped taxonomies

7 Pernicious Kingdoms: Command Injection
CLASP: Command injection
OWASP Top Ten 2007: Injection Flaws (A2) — CWE More Specific fit
OWASP Top Ten 2004: Unvalidated Input (A1) — CWE More Specific fit
OWASP Top Ten 2004: Injection Flaws (A6) — CWE More Specific fit
Software Fault Patterns: Tainted input to command (SFP24)
SEI CERT Perl Coding Standard: Do not pass untrusted, unsanitized data to a command interpreter (IDS34-PL) — CWE More Specific fit

Attack patterns

CAPEC attack patterns that exploit this weakness.

Frequently asked questions

Common questions about CWE-77.

What is CWE-77?: The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
What CVEs are caused by CWE-77?: 3,150 recorded CVEs are attributed to CWE-77, including CVE-2025-10035, CVE-2024-55956, CVE-2005-2773. 34 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Is CWE-77 part of the OWASP Top 10?: CWE-77 maps to OWASP Top Ten 2007: Injection Flaws (A2) in the OWASP security taxonomy.
How do you prevent CWE-77?: If at all possible, use library calls rather than external processes to recreate the desired functionality.
How is CWE-77 detected?: 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.)
What are the consequences of CWE-77?: Exploiting CWE-77 can lead to: Execute Unauthorized Code or Commands.
Is CWE-77 actively exploited?: Yes. 34 CWE-77 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 3,150 recorded CVEs.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

Applies to

How to prevent it

How to detect it

Automated Static Analysis

Code examples

Illustrative examples

Related weaknesses

Parent

Child

Terminology & mappings

Alternate terms

Mapped taxonomies

Attack patterns

Frequently asked questions

References

Track CWE-77 CVEs