The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.

HTTP agents or components may include a web server, load balancer, reverse proxy, web caching proxy, application firewall, web browser, etc. Regardless of the role, they are expected to maintain coherent, consistent HTTP communication state across all components. However, including unexpected data in an HTTP header allows an attacker to specify the entirety of the HTTP message that is rendered by the client HTTP agent (e.g., web browser) or back-end HTTP agent (e.g., web server), whether the message is part of a request or a response.

When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as "splitting" the stream into two different HTTP messages instead of one. CR is carriage return, also given by %0d or \r, and LF is line feed, also given by %0a or \n.
In addition to CR and LF characters, other valid/RFC compliant special characters and unique character encodings can be utilized, such as HT (horizontal tab, also given by %09 or \t) and SP (space, also given as + sign or %20).
These types of unvalidated and unexpected data in HTTP message headers allow an attacker to control the second "split" message to mount attacks such as server-side request forgery, cross-site scripting, and cache poisoning attacks.
HTTP response splitting weaknesses may be present when:

Data enters a web application through an untrusted source, most frequently an HTTP request.
The data is included in an HTTP response header sent to a web user without neutralizing malicious characters that can be interpreted as separator characters for headers.

Primary

HTTP Request Splitting

HTTP Response Splitting

Implementation

Integrity
Access Control
Modify Application Data
Gain Privileges or Assume Identity
CR and LF characters in an HTTP header may give attackers control of the remaining headers and body of the message that the application intends to send/receive, as well as allowing them to create additional messages entirely under their control.

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

Implementation
Input Validation
Construct HTTP headers very carefully, avoiding the use of non-validated input data.

Implementation
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. If an input does not strictly conform to specifications, reject it or transform it into something that conforms.
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
Output Encoding
Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

Implementation
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.

The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

String author = request.getParameter(AUTHOR_PARAM);...Cookie cookie = new Cookie("author", author);cookie.setMaxAge(cookieExpiration);response.addCookie(cookie);

Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

HTTP/1.1 200 OK...Set-Cookie: author=Jane Smith...

However, because the value of the cookie is composed of unvalidated user input, the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as

Wiley Hacker\r\nHTTP/1.1 200 OK\r\n

then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK...Set-Cookie: author=Wiley HackerHTTP/1.1 200 OK...

The second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability to construct arbitrary HTTP responses permits a variety of resulting attacks, including:

cross-user defacement

web and browser cache poisoning

cross-site scripting

page hijacking

An attacker can make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server.

Cross-User Defacement can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server.

In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application.

In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

The impact of a maliciously constructed response can be magnified if it is cached, either by a web cache used by multiple users or even the browser cache of a single user.

Cache Poisoning: if a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected.

Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users.

Cross-Site Scripting: cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser.
The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

In addition to using a vulnerable application to send malicious content to a user, the same weakness can also be leveraged to redirect sensitive content generated by the server to the attacker instead of the intended user.

Page Hijacking: by submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server to the attacker instead of the intended user.
Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

CVE-2020-15811
Chain: Proxy uses a substring search instead of parsing the Transfer-Encoding header (CWE-697), allowing request splitting (CWE-113) and cache poisoning
https://www.cve.org/CVERecord?id=CVE-2020-15811

CVE-2021-41084
Scala-based HTTP interface allows request splitting and response splitting through header names, header values, status reasons, and URIs
https://www.cve.org/CVERecord?id=CVE-2021-41084

CVE-2018-12116
Javascript-based framework allows request splitting through a path option of an HTTP request
https://www.cve.org/CVERecord?id=CVE-2018-12116

CVE-2004-2146
Application accepts CRLF in an object ID, allowing HTTP response splitting.
https://www.cve.org/CVERecord?id=CVE-2004-2146

CVE-2004-1656
Shopping cart allows HTTP response splitting to perform HTML injection via CRLF in a parameter for a url
https://www.cve.org/CVERecord?id=CVE-2004-1656

CVE-2005-2060
Bulletin board allows response splitting via CRLF in parameter.
https://www.cve.org/CVERecord?id=CVE-2005-2060

CVE-2004-2512
Response splitting via CRLF in PHPSESSID.
https://www.cve.org/CVERecord?id=CVE-2004-2512

CVE-2005-1951
e-commerce app allows HTTP response splitting using CRLF in object id parameters
https://www.cve.org/CVERecord?id=CVE-2005-1951

HTTP response splitting

HTTP Response Splitting

25
HTTP Response Splitting

SFP24
Tainted input to command

Allowed
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.
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.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated References, Potential_Mitigations, Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings

CWE Content Team
MITRE
2008-10-14
updated Description

CWE Content Team
MITRE
2008-11-24
updated Description, Other_Notes

CWE Content Team
MITRE
2009-03-10
updated Demonstrative_Examples

CWE Content Team
MITRE
2009-05-27
updated Name

CWE Content Team
MITRE
2009-07-27
updated Demonstrative_Examples, Potential_Mitigations

CWE Content Team
MITRE
2009-10-29
updated Common_Consequences, Description, Other_Notes, Theoretical_Notes

CWE Content Team
MITRE
2010-02-16
updated Taxonomy_Mappings

CWE Content Team
MITRE
2010-06-21
updated Description, Name

CWE Content Team
MITRE
2011-03-29
updated Potential_Mitigations

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Description

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, References, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-06-23
updated Demonstrative_Examples

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2015-12-07
updated Relationships

CWE Content Team
MITRE
2017-05-03
updated Related_Attack_Patterns

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Demonstrative_Examples

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Applicable_Platforms, Potential_Mitigations, Relationships, Type

CWE Content Team
MITRE
2020-06-25
updated Potential_Mitigations

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2022-06-28
4.8
2022-06-28
Critical
Extended the abstraction of this entry to include both HTTP request and response splitting.

CWE Content Team
MITRE
2022-06-28
4.8
2022-06-28
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Theoretical_Notes

CWE Content Team
MITRE
2022-10-13
4.9
2022-10-13
updated Demonstrative_Examples, Related_Attack_Patterns

CWE Content Team
MITRE
2023-01-31
4.10
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
4.11
2023-04-23
updated Detection_Factors, References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-11-19
4.16
2024-11-19
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Relationships, Weakness_Ordinalities

Jonathan Leitschuh
Dan Kaminsky Fellowship @ HUMAN Security
2022-02-25
4.9
2022-10-13
Suggested a new entry for HTTP Request Splitting, leading to scope expansion for CWE-113

HTTP Response Splitting
Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
Failure to Sanitize CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')