HTTP/2 Smuggling Scanner
Tests for HTTP/2 downgrade and smuggling attacks.
What is HTTP/2 Smuggling?
HTTP/2 Smuggling exploits the translation between HTTP/2 (binary framing, no Content-Length ambiguity) and HTTP/1.1 (text-based, header ambiguity). When front-ends accept HTTP/2 and translate to HTTP/1.1 for backends, attackers can inject headers or exploit the translation to smuggle requests.
Why is This Important?
HTTP/2 was expected to solve request smuggling, but translation layers reintroduce vulnerabilities. Many CDNs and load balancers accept HTTP/2 but communicate with backends via HTTP/1.1. This creates new attack surfaces that may be overlooked because HTTP/2 is perceived as 'fixed'.
How It Works
1. Attack Surface Mapping
Identifies complex attack vectors including race conditions, desync points, and logic flaws in your application.
2. Advanced Exploitation
Executes sophisticated attack techniques that bypass traditional security controls and detection mechanisms.
3. Impact Assessment
Demonstrates real-world impact with detailed exploitation chains and business risk analysis.
Key Capabilities
Expert-level security testing for sophisticated vulnerabilities that evade traditional scanning tools.
- Race condition and timing attack detection
- Request smuggling and desync analysis
- Business logic flaw identification
- Chained exploit development
- Protocol-level vulnerability testing
Frequently Asked Questions
How does HTTP/2 downgrade smuggling work?
HTTP/2 allows sending headers that contain characters illegal in HTTP/1.1 (like newlines). When the front-end translates to HTTP/1.1, these become request smuggling vectors. Pseudo-headers (:method, :path) can also be manipulated in ways that translate to smuggling.
What specific techniques exist?
Techniques include: CRLF injection via header values, request splitting through translated headers, H2.CL smuggling (HTTP/2 to Content-Length mismatch), H2.TE smuggling, pseudo-header manipulation, and exploiting differences in header name/value handling during translation.
Why wasn't HTTP/2 immune to smuggling?
HTTP/2 itself handles request boundaries unambiguously via binary framing. The vulnerability exists in the translation layer. Since many backends still only support HTTP/1.1, front-ends must translate, and this translation can introduce smuggling opportunities.
How do I prevent HTTP/2 smuggling?
Prevention: use HTTP/2 end-to-end when possible, carefully validate HTTP/2 to HTTP/1.1 translation, reject requests with problematic header values, update CDN/proxy software regularly, test specifically for HTTP/2 smuggling vectors, and monitor for request anomalies.
Related Scanners
Ready to secure your application?
Start testing for http/2 smuggling vulnerabilities today.
Get Started Free