Request Smuggling

HTTP request smuggling exploits disagreements between HTTP processors about where one request ends and the next begins. When two servers parse the same byte stream differently, an attacker can hide a request inside another.

How Smuggling Works

In a typical architecture, requests flow through layers:

Client  →  CDN / Load Balancer  →  Application Server
           (front-end)              (back-end)

Both must parse the HTTP stream to determine request boundaries. HTTP/1.1 provides two mechanisms:

1. Content-Length — an explicit byte count of the body
2. Transfer-Encoding: chunked — body sent in length-prefixed chunks

When a request contains both headers, or contains them in ambiguous forms, different servers may disagree on the body length. This lets an attacker smuggle a second request inside the first.

CL.TE Example

POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0\r\n\r\nSMUGGLED

Front-end (uses CL: 13): forwards all 13 bytes as one request. Back-end (uses TE: chunked): reads chunk 0 (end), leaves SMUGGLED as the next request.

Real-World Impact

• Bypass authentication — smuggle requests past WAF/auth layers
• Poison web caches — inject responses cached for other users
• Hijack sessions — prepend attacker headers to other users’ requests
• Exfiltrate data — redirect internal responses to attacker endpoints

Scored vs Unscored

Some smuggling tests are unscored because the RFC permits multiple interpretations:

• OWS trimming (Content-Length: 42 with extra space)
• Case-insensitive TE matching (Chunked vs chunked)
• Trailing whitespace in values

For these, 400 is the strict/safe response and 2xx is RFC-compliant. Http11Probe shows 2xx as a warning but does not count it against the score.

Tests

Scored

Unscored