CWE-113 is Improper Neutralization of CRLF Sequences in HTTP Headers. The flaw arises when The product receives data from an HTTP agent or component but fails to neutralize, or incorrectly neutralizes, CR and LF characters before including that data in outgoing HTTP headers. The database currently holds 43 vulnerabilities mapped to CWE-113 and none of them are in the CISA Known Exploited Vulnerabilities catalog.
No vulnerability data in CISA KEV for CWE-113
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. (Roles: Common-Name, Attack-Focused, Common-Name, Attack-Focused)
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 components such as web servers, load balancers, reverse proxies, caching proxies, application firewalls, and browsers are expected to preserve coherent communication state across the request and response path. Unexpected data in a header can cause a client-side or back-end HTTP agent to interpret the resulting stream differently from the application's intent.
When an HTTP request contains unexpected CR and LF characters, the server may interpret the output stream as two HTTP messages rather than one. CR means carriage return and can be represented as %0d or \r; LF means line feed and can be represented as %0a or \n. Other valid or RFC-compliant special characters and character encodings, including HT represented as %09 or \t, and SP represented as + or %20, may also affect interpretation.
If an attacker can control the second message created by the split, the result can support attacks including server-side request forgery, cross-site scripting, and cache poisoning.
This weakness commonly occurs in web-based, language-independent components, including web servers and HTTP intermediaries. Untrusted data is inserted into an HTTP header without correct handling, particularly when it contains CR or LF. Related terms are HTTP request splitting and HTTP response splitting, and the issue can affect both HTTP requests and HTTP responses.
CR and LF characters in an HTTP header may give an attacker control over the remaining headers and body of the intended message, or allow the attacker to create additional messages under their control. The recorded impacts include modifying application data and gaining privileges or assuming another identity. The resulting split-message behavior can also enable server-side request forgery, cross-site scripting, or cache poisoning.
| Impact | Scope | Explanation |
|---|---|---|
| Modify Application Data, Gain Privileges or Assume Identity | Integrity, Access Control | 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. |
Use carefully constructed HTTP headers and avoid placing unvalidated input in them. Apply strict allowlist validation based on the complete specification and relevant properties such as length, type, permitted values, syntax, missing or extra fields, consistency, and business rules; reject or transform inputs that do not conform. Do not rely only on denylists, although denylists can help identify or reject severely malformed input. Decode and canonicalize input into the application's internal representation before validation, and ensure that the same input is not decoded twice. Specify an output encoding that the downstream component can handle, such as ISO-8859-1, UTF-7, or UTF-8, and keep encoding expectations consistent across components.
Automated static analysis, commonly called Static Application Security Testing (SAST), can find some instances by modeling data flow and control flow in source or compiled code. It searches for potentially vulnerable paths from input sources to sinks where data interacts with external components or lower layers. This approach does not necessarily identify every case that depends on runtime behavior or HTTP component configuration.
| Method | Approach | Effectiveness |
|---|---|---|
| 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 |
The following are representative examples curated in the official record, not an exhaustive list:
CVE-2020-15811: A proxy used substring searching instead of parsing the Transfer-Encoding header, enabling request splitting and cache poisoning.CVE-2021-41084: A Scala-based HTTP interface allowed request splitting and response splitting through header names, header values, status reasons, and URIs.CVE-2018-12116: A JavaScript-based framework allowed request splitting through an HTTP request path option.CVE-2004-2146: An application accepted CRLF in an object identifier, allowing HTTP response splitting.CVE-2004-1656: A shopping cart allowed HTTP response splitting and HTML injection through CRLF in a URL parameter.CVE-2005-2060: A bulletin board allowed response splitting through CRLF in a parameter.CVE-2004-2512: Response splitting was possible through PHPSESSID.CVE-2005-1951: An e-commerce application allowed response splitting using CRLF in object identifier parameters.Below are representative vulnerabilities related to this CWE, prioritized by severity.
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
CyStack VulnScan continuously discovers assets, validates vulnerabilities, and helps security teams prioritize remediation across the organization.
Review CyStack's security rating and practical recommendations for websites and edge assets.
Explore cybersecurity research from our team of security specialists.
Browse practical cybersecurity knowledge across CyStack's articles and guides.
en
