Individual skill

http-request-smuggling

Detect HTTP request smuggling by desynchronising front-end and back-end request parsing, using raw-socket timing and differential probes. Use when testing for HTTP desync (CL.TE, TE.CL).

skills/applicative-pentest/http-request-smuggling/SKILL.md

Read pinned source

Source commit 0c1bc93fd5124e7a862d61c1b434f32ba8790e3a

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 5, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
153
Repository last updated
Nov 5, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

## Contents
- Scope & authorization
- Why raw sockets
- Methodology (timing probes then differential confirmation)
- Payloads (CL.TE and TE.CL, exact bytes)
- Runnable snippet
- Output

## Scope & authorization

Request smuggling is an ACTIVE, potentially disruptive check. A successful desync poisons the shared front-end-to-back-end connection: the smuggled prefix can attach to the *next* request on that socket, which in a real deployment may belong to another user. Run this only against hosts you own or are contractually engaged to test, and prefer a low-traffic window. The timing probes (Steps 2-3) are the safest first pass because they never leave a dangling prefix; the differential confirmations (Steps 4-5) do smuggle a real prefix and should follow only once timing suggests a desync.

The vulnerability exists when a request traverses two servers (CDN/load-balancer/reverse-proxy front-end, then an origin back-end) that disagree on where one request ends and the next begins. That disagreement comes from sending both a `Content-Length` (CL) and a `Transfer-Encoding: chunked` (TE) header: if the front-end honors one and the back-end the other, the leftover bytes are "smuggled." A single server with no proxy in front cannot desync, so a negative result on a direct-to-origin host is expected, not a clean bill.