Individual skill

exploiting-http-request-smuggling

Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.

internal/tools/skills/data/web-application-security/exploiting-http-request-smuggling/SKILL.md

Read pinned source

Source commit d42f381ad34843e71a42658e5c57290c713e85af

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 9, 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)
1,325
Repository last updated
Nov 9, 2026
License
Apache-2.0

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

# Exploiting HTTP Request Smuggling

## When to Use

- During authorized penetration tests when the application sits behind a reverse proxy, load balancer, or CDN
- When testing infrastructure with multiple HTTP processors in the request chain (nginx + Apache, HAProxy + Gunicorn)
- For assessing applications for HTTP desynchronization vulnerabilities
- When other attack vectors are limited and you need to bypass front-end security controls
- During security assessments of multi-tier web architectures

### How to CONFIRM a Hit (avoid false negatives)
- The positive signal is a **desync**, not a single clean response. Prove it one of two ways: (a) a time-delay probe (incomplete chunk / mismatched length) that hangs ~5-10s versus an instant baseline, or (b) a smuggled prefix that poisons the *next* request on the same connection — you (or a victim socket) receive a response for an endpoint you did not request, a 400/405 on a normal follow-up request, or your prefix reflected back.
- Always send the paired follow-up request. One smuggling request returning 200 proves nothing; the proof is the second request being corrupted, redirected, or delayed.
- Confirm with a socket-reuse test: fire the attack request, then immediately a normal request on the SAME connection and diff it against the same request on a fresh connection.
Back to top