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.