CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Weakness ID: 150
Vulnerability Mapping:ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities Abstraction:
VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.For users who wish to see all available information for the CWE/CAPEC entry.For users who want to customize what details are displayed.
×
Edit Custom Filter
Description
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
Alternate Terms
ANSI injection
injection of ANSI escape sequences.
Common Consequences
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
Impact
Details
Execute Unauthorized Code or Commands; Hide Activities; Unexpected State
Scope: Integrity
ANSI escape codes can be used for low-severity
attacks such as changing the color of console output,
but they can also be used to arbitrarily move the
cursor, clear the screen, and make fake prompts inside
the interactive CLI via malicious user input. In some
contexts - depending on the functionality of the
terminal in use - ANSI escape codes can be used to
execute arbitrary code.
Potential Mitigations
Phase(s)
Mitigation
Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
Implementation
Strategy: 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.
Implementation
Strategy: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Implementation
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
Implementation
When using output from an LLM, neutralize
or strip escape codes before redirecting output to the
terminal or other rendering engine that would process
the codes. The neutralization could require that the
character be printable and/or allowable whitespace, such
as a carriage return or newline. Be deliberate about
what to allow.
Effectiveness: High
Note: By restricting output to only printable
characters, this effectively removes any escape codes.
Build and Compilation
When using an LLM: during tokenizer
training, suppress escape codes from the tokenizer's
vocabulary. Depending on context, this could be
accomplished by removing the codes from input to the
tokenizer, or removing the map from the string to its
token ID. It is generally unlikely that this removal
would adversely affect the quality or correctness of
what is generated, e.g. advice requests for terminal
settings to change colors.
Effectiveness: Limited
Note: This could raise the exploitation
effort for an adversary, but the adversary might still
be able to get string together multiple tokens in order
to form the escape code.
Relationships
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Nature
Type
ID
Name
ChildOf
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
Phase
Note
Build and Compilation
During LLM training, escape sequences may be
assigned within token entry values.
Implementation
Interactive command line interfaces have become
more commonplace with growing system administration
needs and human-friendly TUIs (text-based user
interfaces); logging user-generated values into the
terminal into one of these sessions is no longer
safe.
Implementation
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Applicable Platforms
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages
Class: Not Language-Specific
(Undetermined Prevalence)
Technologies
AI/ML
(Undetermined Prevalence)
Demonstrative Examples
Example 1
Consider a situation in which an AI agent
uses LLM output based on training data from untrusted
sources.
Suppose an attacker is able to inject input
into the training data that is used by the LLM. If a
person is using a terminal emulator to interact with the
LLM on the command line, if the output contains escape
codes, then the emulator might act on those codes, e.g.,
to change color, flash text, or (in some cases) leak
sensitive information or execute code. In one documented
case, a terminal would handle an OSC (Operating System
Command) for setting the working directory by processing
a file:// URL in a way that could perform a DNS lookup
for an adversary-controlled domain, leading to an
information leak [REF-1526].
Selected Observed
Examples
Note: this is a curated list of examples for users to understand the variety of ways in which this
weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
Chain: JavaScript-based application removes ANSI escape sequences in a dialog that asks permission for a particular file, causing the wrong filename to be visually presented for user approval (CWE-451), but the filename still contains the ANSI escape sequences (CWE-150), potentially causing the user to grant access to the wrong file.
MFV. (multi-channel). Injection of control characters into log files that allow information hiding when using raw Unix programs to read the files.
Weakness Ordinalities
Ordinality
Description
Primary
(where the weakness exists independent of other weaknesses)
Detection
Methods
Method
Details
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
Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Nature
Type
ID
Name
MemberOf
Category - a CWE entry that contains a set of other entries that share a common characteristic.
(this CWE ID may be used to map to real-world vulnerabilities)
Reason
Acceptable-Use
Rationale
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Notes
Research Gap
As of CWE 4.20: while
exploitation and research interest in ANSI escape codes
(and other terminal sequences) was popular in the early
2000's [REF-1527] - and known as an attack vector going
back to at least 1994 [REF-1532] - there has been renewed
interest in this type of injection as new attack vectors
have arrived (e.g., from LLM output, or CLIs that were not
based on OS sessions).
Taxonomy
Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Escape, Meta, or Control Character / Sequence
The CERT Oracle Secure Coding Standard for Java (2011)
Suggested coverage of LLM-specific considerations, providing modes of introduction, mitigations, references, and a demonstrative example. Additional feedback provided by the CWE AI WG.
2024-06-15
(CWE 4.20, 2026-04-30)
GitHub user tristan-f-r
suggested changes that were integrated into observed examples, common consequences, references, and others.
Description
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
