CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

CRLF has syntactic meaning in many line-oriented formats and communications. If an application places unvalidated input where CRLF is interpreted, an input provider can add line or record boundaries and change the structure processed by the application or a downstream component. Data intended to remain content can therefore become part of a message structure, log entry, or outgoing data, enabling modification of application data.

This weakness occurs when input can contain CRLF and the application passes it to a component that uses CRLF to delimit lines or records. Without appropriate neutralization, supplied data can alter line or record boundaries instead of being handled solely as content. The weakness is not language-specific and is recorded as arising during implementation.

The recorded consequence is an integrity impact: an attacker may modify application data by injecting additional lines, records, or headers where CRLF is interpreted. The representative cases include altered outgoing-request headers, spoofed log entries, added mail headers, and HTTP response splitting.

During implementation, avoid using CRLF as a special sequence where possible. Appropriately filter or quote CRLF sequences in user-controlled input before the input is used in a context that interprets CRLF.

Automated static analysis, commonly called Static Application Security Testing (SAST), can identify some instances by analyzing source or binary/compiled code without execution. It typically models data flow and control flow, then searches for potentially vulnerable patterns connecting input sources to sinks where data interacts with external components or lower layers such as the operating system. The recorded effectiveness is high, although this approach does not necessarily find every instance.

The following are representative examples, not an exhaustive list:

• CVE-2002-1771: CRLF injection enabled a spam proxy by adding mail headers using an email address or name.
• CVE-2002-1783: CRLF injection in API function arguments allowed headers for outgoing requests to be modified.
• CVE-2004-1513: Carriage returns enabled spoofed entries in a web server log file.
• CVE-2006-4624: A chain allowed fake log entries with fake timestamps to be injected using CRLF injection.
• CVE-2005-1951: A chain in which the application accepted CRLF in an object ID allowed HTTP response splitting.
• CVE-2004-1687: A chain enabled HTTP response splitting through CRLF in a parameter related to a URL.