Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Incomplete Base

Structure: Simple

Description

This weakness occurs when a proxy, firewall, or other intermediary HTTP agent interprets a malformed HTTP request or response differently than the final destination server or client. This inconsistency allows an attacker to craft messages that bypass the intermediary's security checks.

Extended Description

HTTP request smuggling exploits differences in how web servers, clients, and intermediary devices (like load balancers, reverse proxies, or WAFs) parse ambiguous HTTP messages. An attacker can inject conflicting headers—such as duplicate `Content-Length` or `Transfer-Encoding` fields—causing the intermediary and the backend server to see two different requests or responses in the same network stream. This lets malicious traffic slip through undetected. This vulnerability typically stems from using outdated HTTP parsing libraries or mismatched protocol versions between system components. To prevent it, developers must ensure all HTTP agents in the data flow use consistent, up-to-date parsing logic and rigorously validate message formatting.

Common Consequences 1

Scope: IntegrityNon-RepudiationAccess Control

Impact: Unexpected StateHide ActivitiesBypass 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).

Potential Mitigations 4

Phase: Implementation

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

Phase: Implementation

Use only SSL communication.

Phase: Implementation

Terminate the client session after each request.

Phase: System Configuration

Turn all pages to non-cacheable.

Demonstrative Examples 3

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.

Code Example:

Attack

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:

Code Example:

Result

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:

Code Example:

Attack

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.

Code Example:

Attack

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:

Code Example:

Attack

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.

Code Example:

Good

Java

java

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

java

// output error response* } else { ```

java

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.

Code Example:Attack
bash

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.

Code Example:

Attack

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"

... "Malicious Code"

Observed Examples 6

CVE-2022-24766SSL/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

CVE-2021-37147Chain: caching proxy server has improper input validation (Improper Input Validation) of headers, allowing HTTP response smuggling (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')) using an "LF line ending"

CVE-2020-8287Node.js platform allows request smuggling via two Transfer-Encoding headers

CVE-2006-6276Web servers allow request smuggling via inconsistent HTTP headers.

CVE-2005-2088HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header

CVE-2005-2089HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header

References 7

HTTP Request Smuggling

Chaim Linhart, Amit Klein, Ronen Heled, and Steve Orrin

https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf(2023-04-07)

ID: REF-433

HTTP Response Smuggling

Robert Auger

01-02-2011

http://projects.webappsec.org/w/page/13246930/HTTP%20Response%20Smuggling

ID: REF-1273

HTTP Request Smuggling: Complete Guide to Attack Types and Prevention

Dzevad Alibegovic

23-08-2021

https://brightsec.com/blog/http-request-smuggling-hrs/

ID: REF-1274

A Pentester's Guide to HTTP Request Smuggling

Busra Demir

15-10-2020

https://www.cobalt.io/blog/a-pentesters-guide-to-http-request-smuggling

ID: REF-1275

HTTP Desync Attacks in the Wild and How to Defend Against Them

Edi Kogan and Daniel Kerman

29-10-2019

https://www.imperva.com/blog/archive/http-desync-attacks-and-defence-methods/(2025-08-04)

ID: REF-1276

HTTP Desync Attacks: Request Smuggling Reborn

James Kettle

07-08-2019

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn(2023-04-07)

ID: REF-1277

HTTP request smuggling

PortSwigger

https://portswigger.net/web-security/request-smuggling(2023-04-07)

ID: REF-1278

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Technologies:

Web Based : Undetermined

Modes of Introduction

Implementation

Related Attack Patterns

Alternate Terms

HTTP Request Smuggling

HTTP Response Smuggling

HTTP Smuggling

Related Weaknesses

ChildOf:

Interpretation Conflict (CWE-436)

ChildOf:

Interpretation Conflict (CWE-436)

Taxonomy Mapping

PLOVER
WASC
WASC

Notes

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