Test for HTTP Request Smuggling with Burp Suite (2026)

HTTP Request Smuggling is a surprisingly potent attack that exploits how different web servers, or even different components within the same server, interpret the boundaries of HTTP requests.

Let’s see this in action. Imagine a front-end proxy server and a back-end application server. The proxy might receive a request and, based on the Content-Length header, decide where the request ends. The back-end, however, might be configured to use the Transfer-Encoding: chunked header to determine the end of the request. If these interpretations diverge, an attacker can craft a single request that the proxy sees as one thing, but the back-end sees as two distinct requests.

Consider this scenario:

Attacker’s Request (sent to the proxy):

POST /some/path HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: bar

Proxy’s Interpretation: The proxy sees Content-Length: 4. It reads the first four bytes of the body, which are 0\r\n\r\n. It considers this the complete request and forwards it to the back-end.

Back-end’s Interpretation: The back-end sees Transfer-Encoding: chunked. It processes the 0\r\n\r\n as the end of a chunked request body. However, it doesn’t stop there. It then processes the next sequence of bytes it receives as a new, completely separate request. This "second" request is GET /admin HTTP/1.1\r\nHost: vulnerable-website.com\r\nFoo: bar\r\n.

The attacker has just smuggled a request for /admin to the back-end, which might be a hidden administrative endpoint, by making it appear as part of the initial POST request to the proxy. This allows them to bypass access controls that might be enforced by the proxy.

Burp Suite’s Role

Burp Suite is invaluable for detecting and exploiting these vulnerabilities. Here’s how you’d typically approach it:

1. Identify Potential Targets: Look for applications that use multiple HTTP components, especially a front-end proxy (like a load balancer, WAF, or CDN) interacting with a back-end application server.

2. Crafting Test Requests: The core of testing for request smuggling lies in sending requests that have both a Content-Length header and a Transfer-Encoding: chunked header. The goal is to create a situation where these two headers would lead to different interpretations of the request boundary.

   • Ambiguity: The most common way to trigger this is by having a Content-Length that is shorter than the actual body, and then using Transfer-Encoding: chunked. The Content-Length will terminate the request for the front-end, while the chunked encoding will be processed by the back-end.

   • Obfuscation: Sometimes, the Transfer-Encoding header might be slightly malformed or obfuscated (e.g., Transfer-Encoding: \tchunked, Transfer-Encoding: chunked \r\n, Transfer-Encoding: xchunked if the back-end is lenient). This can cause the front-end to ignore Transfer-Encoding and rely on Content-Length, while the back-end might still process it.

3. Using Burp Repeater:

   • Send a request to the target through Burp Proxy.
   • Right-click the request and select "Send to Repeater."
   • In Repeater, modify the request. A common starting point is to add a Transfer-Encoding: chunked header to a request that already has a Content-Length header. You’ll need to adjust the Content-Length to be short enough to allow for smuggled data.

   Example Test Request (in Burp Repeater):

   POST /some/path HTTP/1.1
   Host: vulnerable-website.com
   Content-Length: 4
   Transfer-Encoding: chunked
   
   0
   
   GET /admin HTTP/1.1
   Host: vulnerable-website.com
   Foo: bar
   

   • Explanation: The Content-Length: 4 tells the front-end to only read 0\r\n. The back-end, processing Transfer-Encoding: chunked, sees the 0\r\n\r\n as the end of the chunked body and then processes the subsequent GET /admin... as a new request.

4. Analyzing the Response:

   • Send the crafted request.
   • Observe the response. If you get a response for /admin (or any other unexpected resource) when you only requested /some/path, you’ve likely found a smuggling vulnerability.
   • Key Indicator: A common technique is to smuggle a request for a resource that returns a distinct response, like an error page, or a specific HTML snippet. If you see that distinct response when you expected something else, it’s a strong sign.

5. Exploitation Techniques:

   • Cache Poisoning: Smuggle a request that causes the front-end cache to serve malicious content for a legitimate URL.
   • Session Hijacking: Smuggle a request that forces a user’s browser to send their session cookie to an attacker-controlled server.
   • Bypassing Access Controls: As shown in the example, smuggle requests to sensitive endpoints that are normally protected.

   The CL.TE Vulnerability (Content-Length vs. Transfer-Encoding): This is the classic scenario. The front-end honors Content-Length, while the back-end honors Transfer-Encoding.

   The TE.CL Vulnerability (Transfer-Encoding vs. Content-Length): Here, the front-end honors Transfer-Encoding, and the back-end honors Content-Length. This is less common but still possible if the front-end is more strict about chunking than the back-end.

   The TE.TE Vulnerability (Transfer-Encoding vs. Transfer-Encoding): This occurs when both front-end and back-end honor Transfer-Encoding, but one of them has a bug in how it processes chunked encoding, especially with obfuscated headers or malformed chunk sizes.

   Burp’s HTTP Request Smuggler Extension: For more advanced or automated testing, Burp Suite has an extension called "HTTP Request Smuggler" which can automate many of these tests. It probes for various smuggling techniques and attempts to confirm them.

   A subtle point often missed is how different servers handle malformed chunked encoding. For instance, a server might strip whitespace or specific characters from the Transfer-Encoding header before parsing it. If the front-end strips it and falls back to Content-Length, while the back-end doesn’t strip it and proceeds with chunked encoding, this creates a TE.CL vulnerability. Always test variations of the Transfer-Encoding header, like Transfer-Encoding: \tchunked or Transfer-Encoding: chunked\r\n to see if the front-end or back-end is more lenient in its parsing.

Once you’ve successfully smuggled a request and received the correct response for your smuggled request, the next immediate challenge is often to reliably trigger this across multiple requests and to ensure the smuggled request is processed by the intended backend instance, especially in distributed environments.