Detecting HTTP request smuggling without attacking anyone.

Request smuggling is one of the highest-impact web bugs and one of the most dangerous to confirm — the textbook proof traps a real user's request. VirtuProbe finds the desync by timing, not by poisoning anyone. Here's how CL.TE and TE.CL work, why the usual confirmation step is the risky part, and how a timing check flags the bug with no collateral damage.

What request smuggling actually is

Put a front-end (a proxy or load balancer) in front of a back-end and they have to agree on one thing for every request: where it ends and the next one begins. They disagree when a request declares its length two ways at once — a Content-Length header and Transfer-Encoding: chunked. If the front-end trusts one and the back-end trusts the other, part of your request gets left in the back-end's buffer and glued onto the front of whatever request comes next.

That's a desync. CL.TE is front-end-uses-Content-Length, back-end-uses-Transfer-Encoding; TE.CL is the reverse. Either way, one connection's leftovers become another connection's prefix.

Why confirming it is the dangerous part

The classic confirmation smuggles a partial request that sits in the back-end's buffer and prepends itself to the next request that arrives. In a lab that's your own follow-up request. On a live system it might be a stranger's — which is how request-smuggling proofs end up capturing or corrupting real users' traffic. That's precisely the move you do not want to get subtly wrong against anything but a target you own.

Measure the stall, don't poison the buffer

VirtuProbe's desync check takes the other road: it doesn't leave a trap, it times a stall. The trick is to craft a request so that if the two servers disagree about framing, the back-end sits waiting for bytes that never arrive — and the exchange hangs. A desync then shows up as a timeout or a gateway error measured against a fast baseline. Nothing is left in a buffer to prepend to a victim.

It runs three vectors and compares them: a BASELINE, a CL.TE timing probe, and a TE.CL timing probe.

The verdicts

Each run comes back with one of a small set of verdicts:

• BASELINE — the reference timing for a well-formed request.
• NORMAL — no meaningful deviation; no desync detected.
• DESYNC — a gateway-timeout status (504/502/408) or a latency spike well past baseline: the framing disagreement is real.
• INCONCLUSIVE — the connection wobbled (a raw transport stall) but not cleanly enough to call.
• ERROR — the probe itself couldn't complete.

Why this needs a client that sends raw bytes

You cannot send a Content-Length that lies, or a Transfer-Encoding the runtime quietly strips, through a normalising HTTP library — it repairs your malformed framing before it ever reaches the wire, and the malformed framing is the entire test. VirtuProbe's HTTP client is hand-written and sends the bytes you give it verbatim. When the exchange ends below the HTTP layer, it reports how, as a transport outcome — OK, EOF, RST, TIMEOUT, MALFORMED_RESPONSE, PARTIAL. That outcome is the signal the detector reads.

# A CL.TE-shaped request: two lengths, one wire
POST / HTTP/1.1
Host: target.example
Content-Length: 6
Transfer-Encoding: chunked

0

X

The related mutations

The same raw foundation drives a mutation fuzz mode that generates malformed framings on purpose, so you can watch how a stack reacts to each one. The current mutators: lf-line-endings, dup-content-length, cl-te-conflict, drop-content-length, bare-lf-header, and space-before-colon. Fire them and watch the transport outcome and status code deviate from the baseline.

Jakub Stonavský is the founder and maintainer of VirtuProbe Studio, based in Prague. More about the project →