The product acts as an intermediary HTTP agent
(such as a proxy or firewall) in the data flow between two
entities such as a client and server, but it does not
interpret malformed HTTP requests or responses in ways that
are consistent with how the messages will be processed by
those entities that are at the ultimate destination.

HTTP requests or responses ("messages") can be
malformed or unexpected in ways that cause web servers or
clients to interpret the messages in different ways than
intermediary HTTP agents such as load balancers, reverse
proxies, web caching proxies, application firewalls,
etc. For example, an adversary may be able to add duplicate
or different header fields that a client or server might
interpret as one set of messages, whereas the intermediary
might interpret the same sequence of bytes as a different
set of messages. For example, discrepancies can arise in
how to handle duplicate headers like two Transfer-encoding
(TE) or two Content-length (CL), or the malicious HTTP
message will have different headers for TE and
CL.
The inconsistent parsing and interpretation of messages
can allow the adversary to "smuggle" a message to the
client/server without the intermediary being aware of it.
This weakness is usually the result of the usage
of outdated or incompatible HTTP protocol versions in the
HTTP agents.

Primary

Resultant

HTTP Request Smuggling

HTTP Response Smuggling

HTTP Smuggling

Implementation

Integrity
Non-Repudiation
Access Control
Unexpected State
Hide Activities
Bypass Protection Mechanism
An attacker could create HTTP messages to exploit a number of weaknesses including 1) the message can trick the web server to associate a URL with another URL's webpage and caching the contents of the webpage (web cache poisoning attack), 2) the message can be structured to bypass the firewall protection mechanisms and gain unauthorized access to a web application, and 3) the message can invoke a script or a page that returns client credentials (similar to a Cross Site Scripting attack).

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

Implementation
Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].

Implementation
Use only SSL communication.

Implementation
Terminate the client session after each request.

System Configuration
Turn all pages to non-cacheable.

In the following example, a malformed HTTP request is sent to a website that includes a proxy server and a web server with the intent of poisoning the cache to associate one webpage with another malicious webpage.

POST http://www.website.com/foobar.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 54

GET /poison.html HTTP/1.1
Host: www.website.com
Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

When this request is sent to the proxy server, the proxy server parses the first four lines of the POST request and encounters the two "Content-Length" headers. The proxy server ignores the first header, so it assumes the request has a body of length 54 bytes. Therefore, it treats the data in the next three lines that contain exactly 54 bytes as the first request's body:

GET /poison.html HTTP/1.1
Host: www.website.com
Bla:

The proxy then parses the remaining bytes, which it treats as the client's second request:

GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

The original request is forwarded by the proxy server to the web server. Unlike the proxy, the web server uses the first "Content-Length" header and considers that the first POST request has no body.

POST http://www.website.com/foobar.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 54 (ignored by server)

Because the web server has assumed the original POST request was length 0, it parses the second request that follows, i.e. for GET /poison.html:

GET /poison.html HTTP/1.1
Host: www.website.com
Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

Note that the "Bla:" header is treated as a regular header, so it is not parsed as a separate GET request.
The requests the web server sees are "POST /foobar.html" and "GET /poison.html", so it sends back two responses with the contents of the "foobar.html" page and the "poison.html" page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client - "POST /foobar.html" and "GET /page_to_poison.html". If the response is cacheable, the proxy caches the contents of "poison.html" under the URL "page_to_poison.html", and the cache is poisoned! Any client requesting "page_to_poison.html" from the proxy would receive the "poison.html" page.
When a website includes both a proxy server and a web server, some protection against this type of attack can be achieved by installing a web application firewall, or using a web server that includes a stricter HTTP parsing procedure or make all webpages non-cacheable.
Additionally, if a web application includes a Java servlet for processing requests, the servlet can check for multiple "Content-Length" headers and if they are found the servlet can return an error response thereby preventing the poison page to be cached, as shown below.

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Set up response writer object
...try {

// check for multiple content length headers
Enumeration contentLengthHeaders = request.getHeaders("Content-Length");
int count = 0;
while (contentLengthHeaders.hasMoreElements()) {
count++;
}
if (count > 1) {

// output error response
}
else {

// process request

}

} catch (Exception ex) {...}
}

In the following example, a malformed HTTP request is sent to a website that includes a web server with a firewall with the intent of bypassing the web server firewall to smuggle malicious code into the system.

POST /page.asp HTTP/1.1Host: www.website.comConnection: Keep-AliveContent-Length: 49223
zzz...zzz ["z" x 49152]POST /page.asp HTTP/1.0Connection: Keep-AliveContent-Length: 30
POST /page.asp HTTP/1.0Bla: POST /page.asp?cmd.exe HTTP/1.0Connection: Keep-Alive

When this request is sent to the web server, the first POST request has a content-length of 49,223 bytes, and the firewall treats the line with 49,152 copies of "z" and the lines with an additional lines with 71 bytes as its body (49,152+71=49,223). The firewall then continues to parse what it thinks is the second request starting with the line with the third POST request.
Note that there is no CRLF after the "Bla: " header so the POST in the line is parsed as the value of the "Bla:" header. Although the line contains the pattern identified with a worm ("cmd.exe"), it is not blocked, since it is considered part of a header value. Therefore, "cmd.exe" is smuggled through the firewall.
When the request is passed through the firewall the web server the first request is ignored because the web server does not find an expected "Content-Type: application/x-www-form-urlencoded" header, and starts parsing the second request.
This second request has a content-length of 30 bytes, which is exactly the length of the next two lines up to the space after the "Bla:" header. And unlike the firewall, the web server processes the final POST as a separate third request and the "cmd.exe" worm is smuggled through the firewall to the web server.
To avoid this attack a Web server firewall product must be used that is designed to prevent this type of attack.

The interpretation of HTTP responses can be manipulated if response headers include a space between the header name and colon, or if HTTP 1.1 headers are sent through a proxy configured for HTTP 1.0, allowing for HTTP response smuggling. This can be exploited in web browsers and other applications when used in combination with various proxy servers. For instance, the HTTP response interpreted by the front-end/client HTTP agent/entity - in this case the web browser - can interpret a single response from an adversary-compromised web server as being two responses from two different web sites. In the Example below, notice the extra space after the Content-Length and Set-Cookie headers.

HTTP/1.1 200 OK
Date: Fri, 08 Aug 2016 08:12:31 GMT
Server: Apache (Unix)
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Content-Length : 2345
Transfer-Encoding: chunked
Set-Cookie : token="Malicious Code"

<HTML> ... "Malicious Code"

CVE-2022-24766
SSL/TLS-capable proxy allows HTTP smuggling when used in tandem with HTTP/1.0 services, due to inconsistent interpretation and input sanitization of HTTP messages within the body of another message
https://www.cve.org/CVERecord?id=CVE-2022-24766

CVE-2021-37147
Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
https://www.cve.org/CVERecord?id=CVE-2021-37147

CVE-2020-8287
Node.js platform allows request smuggling via two Transfer-Encoding headers
https://www.cve.org/CVERecord?id=CVE-2020-8287

CVE-2006-6276
Web servers allow request smuggling via inconsistent HTTP headers.
https://www.cve.org/CVERecord?id=CVE-2006-6276

CVE-2005-2088
HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header
https://www.cve.org/CVERecord?id=CVE-2005-2088

CVE-2005-2089
HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header
https://www.cve.org/CVERecord?id=CVE-2005-2089

HTTP Request Smuggling

26
HTTP Request Smuggling

27
HTTP Response Smuggling

Allowed
This CWE entry is at the Base 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.

Request smuggling can be performed due to a multiple interpretation error, where the target is an intermediary or monitor, via a consistency manipulation (Transfer-Encoding and Content-Length headers).

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

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

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

CWE Content Team
MITRE
2009-05-27
updated Name, Related_Attack_Patterns

CWE Content Team
MITRE
2010-02-16
updated Taxonomy_Mappings

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

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

CWE Content Team
MITRE
2012-10-30
updated Demonstrative_Examples, Potential_Mitigations

CWE Content Team
MITRE
2014-06-23
updated Other_Notes, Potential_Mitigations, Theoretical_Notes

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2015-12-07
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms

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

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2022-04-28
updated Related_Attack_Patterns

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

CWE Content Team
MITRE
2022-06-28
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, References, Taxonomy_Mappings

CWE Content Team
MITRE
2022-10-13
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated References, Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

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

HTTP Request Smuggling
Interpretation Conflict in Web Traffic (aka 'HTTP Request Smuggling')
Inconsistent Interpretation of HTTP Requests (aka 'HTTP Request Smuggling')
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')