CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences

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.

Affected languages: Not Language-Specific
Affected technologies: AI/ML
Parent weaknesses: CWE-138

Consequences:
  - Integrity: Execute Unauthorized Code or Commands

Detection methods:
  - 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 havin

Mitigations:
  - 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] 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 pe
  - [Implementation] 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
  - [Implementation] 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 i

Demonstrative examples:
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-15

Real-world examples:
  - CVE-2024-27936: 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
  - CVE-2002-0542: The mail program processes special "~" escape sequence even when not in interactive mode.
  - CVE-2000-0703: Setuid program does not filter escape sequences before calling mail program.
  - CVE-2002-0986: Mail function does not filter control characters from arguments, allowing mail message content to be modified.
  - CVE-2003-0020: Multi-channel issue. Terminal escape sequences not filtered from log files.