The product builds a command, data structure, or record from externally influenced input but fails to neutralize, or incorrectly neutralizes, special elements that can change how a downstream component parses or interprets that output.
The product 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.
This weakness occurs across a boundary between an upstream source of input and a downstream interpreter or component. When control-plane syntax is allowed to remain mixed with ordinary data, the downstream component may treat attacker-influenced content as commands, expressions, options, scripts, or other instructions rather than as data. The specific result depends on the downstream component, but the underlying failure is improper neutralization of syntax that has special meaning in that component.
This is a language-independent weakness introduced during implementation. It is characterized by a data flow from an externally influenced source to a downstream sink where special syntax is parsed, with insufficient separation between data and control information. The record rates its likelihood of exploitation as high and marks the entry as incomplete, so the documented behavior should not be treated as an exhaustive description of every injection form.
Potential consequences include disclosure of application data and bypass of protection mechanisms, including authentication-related controls. Injected control information can alter execution logic and, in some cases, enable arbitrary code execution. It can also compromise data integrity, while injected actions may be unlogged and therefore hide activity or weaken non-repudiation.
| Impact | Scope | Explanation |
|---|---|---|
| Read Application Data | Confidentiality | Many injection attacks involve the disclosure of important information -- in terms of both data sensitivity and usefulness in further exploitation. |
| Bypass Protection Mechanism | Access Control | In some cases, injectable code controls authentication; this may lead to a remote vulnerability. |
| Alter Execution Logic | Other | Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code. |
| Other | Integrity, Other | Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. |
| Hide Activities | Non-Repudiation | Often the actions performed by injected control code are unlogged. |
Requirements: Choose programming languages and supporting technologies that are not subject to the relevant injection issues where feasible. Implementation: Apply an appropriate combination of allowlist and denylist parsing to filter control-plane syntax from all input, while accounting for the syntax expected by the downstream component.
Automated static analysis: SAST can identify some instances without executing the program by modeling data flow and control flow, then looking for risky paths from input sources to sinks where data interacts with external components or lower layers such as the operating system. Its documented effectiveness is high, but the method is described as finding only some instances, so it does not establish that all injection paths are absent.
| 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 |
The official record provides these representative examples, not an exhaustive list: CVE-2024-5184 involved direct prompt injection in an API service using a large generative AI model, exposing hard-coded system prompts or enabling other prompts to execute. CVE-2022-36069 avoided OS command injection while generating Git commands but allowed injected optional arguments beginning with a dash, potentially leading to code execution. CVE-1999-0067 is a canonical OS command injection case in which a CGI program failed to neutralize the | metacharacter when invoking a phonebook program. Other examples include CVE-2022-1509, involving injection of sed script syntax; CVE-2020-9054, where improper username validation led to OS command injection and was exploited in the wild; and CVE-2021-44228, where unneutralized ${xyz} expressions enabled remote code execution.
Below are representative vulnerabilities related to this CWE, prioritized by severity.
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
CyStack VulnScan continuously discovers assets, validates vulnerabilities, and helps security teams prioritize remediation across the organization.
Explore CyStack VulnScan
en
