request-smuggling

Detect HTTP request smuggling and desync vulnerabilities across front-end and back-end proxies.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/AshtonVaughan/bountyhound --skill request-smuggling-ashtonvaughan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: request-smuggling
Source: https://github.com/AshtonVaughan/bountyhound/tree/main/bountyhound/skills/request-smuggling
Command: npx skills add https://github.com/AshtonVaughan/bountyhound --skill request-smuggling-ashtonvaughan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

HTTP request smuggling and desync vulnerabilities in modern web architectures can allow attackers to bypass security controls and confuse downstream systems. This Skill provides a disciplined methodology to identify and verify such flaws across front-end proxies and back-end services within authorized bug bounty programs.

Core Features & Use Cases

  • End-to-end desync discovery across CL.TE, TE.CL, TE.TE, H2.CL, H2.TE, and browser-based desync scenarios.
  • Phase-driven workflow including infrastructure fingerprinting, multi-variant testing, self-smuggle proofs, and safety-focused reporting.
  • Use cases include testing behind CDNs/reverse proxies, validating WAF bypass potential, detecting potential cache poisoning, and generating evidence-ready PoC reports.

Quick Start

Start by running a timing-based CL.TE probe against the target and follow with a self-smuggle proof on the same connection to confirm desync within scope.

Frequently Asked Questions about request-smuggling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect HTTP request smuggling vulnerabilities in front-end and back-end proxy architectures?▼

HTTP request smuggling detection involves running timing-based probes and self-smuggle proofs against front-end and back-end proxies to identify desync vulnerabilities like CL.TE and TE.CL within authorized targets.

What is the best way to test for HTTP desync scenarios like H2.CL and H2.TE?▼

Testing for HTTP desync scenarios requires applying a phase-driven workflow that fingerprints infrastructure, executes multi-variant timing probes for H2.CL and H2.TE, and confirms desync with self-smuggle proofs on the same connection.

How do I generate proof-of-concept payloads for HTTP request smuggling bug bounty reports?▼

Generating PoC payloads for HTTP request smuggling requires executing self-smuggle proofs within scope, documenting timing evidence, and producing a compliant report that satisfies safety and reporting requirements for authorized bug bounty programs.

Can I use timing probes to identify TE.TE and browser-based desync vulnerabilities behind CDNs?▼

Yes, timing probes can identify TE.TE and browser-based desync vulnerabilities behind CDNs and reverse proxies by detecting synchronization discrepancies between front-end and back-end systems during multi-variant testing.

Does HTTP request smuggling testing require authorization before probing targets for WAF bypass potential?▼

Yes, HTTP request smuggling testing must be conducted within authorized bug bounty programs, ensuring all timing probes, self-smuggle proofs, and PoC payloads are generated strictly within the defined scope to maintain safety compliance.

Why does HTTP request smuggling require multi-variant testing across CL.TE, TE.CL, and TE.TE scenarios?▼

Multi-variant testing is required because HTTP request smuggling manifests differently depending on how front-end and back-end proxies parse Content-Length and Transfer-Encoding headers, necessitating checks across CL.TE, TE.CL, and TE.TE scenarios.