CWE-138, Improper Neutralization of Special Elements, is a class-level weakness. The product receives input from an upstream component but does not neutralize, or incorrectly neutralizes, special elements that the downstream component could read as control elements or syntactic markers.
It is language-neutral. Anywhere data moves from one component to another that has its own syntax, this weakness can appear. Shells, databases, mail programs, log viewers, terminals and file formats all have special characters.
How it happens
Most languages and protocols reserve certain characters and words. MITRE gives a neat example: both Unix and Windows interpret the symbol < as meaning "read input from a file". Input that was meant as plain text becomes an instruction.
The pattern is always the same.
- Data arrives from somewhere you do not control.
- Your code builds a message, command, record or document from it.
- The next component parses that message and treats some characters as control.
- The attacker supplies those characters.
MITRE's examples show the range of downstream components.
- CVE-2001-0677: a special MIME header, used internally to store pathnames for attachments, lets an attacker read arbitrary files from a mail client.
- CVE-2000-0703: a setuid program does not cleanse a special escape sequence before sending data to a mail program, which processes the sequence.
- CVE-2003-0020 and CVE-2003-0083: terminal escape sequences not filtered from log files, which MITRE labels multi-channel issues.
The specific cases have their own pages: CWE-140 for delimiters, and children such as CWE-141 through CWE-148 for specific delimiter kinds. Well-known members of the wider family include shell, SQL and script injection.
What an attacker gains
MITRE's consequence entry covers confidentiality, integrity and availability. The attacker may execute unauthorized code or commands, alter execution logic, or crash the program. The outcome depends on what the downstream component can do. A mail client that reads files, a shell that runs commands, and a terminal that follows escape sequences each give a different prize.
How to find it
The record has no detection entries, so use the approach that fits the pattern.
- Trace each input to every place it is placed inside another syntax: command lines, queries, templates, headers, file paths, log messages.
- Test with the special characters of each downstream format, one format at a time.
- Look for places where code removes some characters by hand. Hand-written filters tend to miss one.
- Run static analysis rules that follow tainted data to command, query and output sinks.
How to fix it
The record lists no mitigations. These steps are widely accepted practice for this class.
- Name the downstream component for every piece of untrusted data.
- Use an API that keeps data and control separate: parameterized queries, argument arrays instead of shell strings, and structured logging.
- When you must build a string in the target syntax, apply the escaping that belongs to that syntax, from a maintained library.
- Validate input against what is expected, such as allowed characters, lengths and formats, and reject the rest.
- Neutralize at the point of use, not only at entry, because the same data may flow to several different consumers.
- Strip or encode control characters before writing to logs or terminals.
# Vulnerable: input becomes part of a shell command line
os.system("convert " + filename + " out.png")
# Fixed: arguments are passed as data, no shell parses them
subprocess.run(["convert", filename, "out.png"], check=True)
Quick check
What is the core idea behind injection weaknesses?
Data is placed into a message that another component parses, and special characters in the data are treated as instructions.
Is blocklisting dangerous characters enough?
Rarely. Blocklists miss variants. Prefer APIs that separate data from control, plus escaping from a maintained library for the target syntax.
