Request Smuggling - TE.CL Scanner
Tests for TE.CL HTTP request smuggling attacks.
What is Request Smuggling - TE.CL?
TE.CL HTTP request smuggling is the inverse of CL.TE: the front-end server uses Transfer-Encoding: chunked while the back-end uses Content-Length. Attackers craft requests that the front-end processes as chunked but the back-end interprets based on Content-Length, enabling request smuggling.
Why is This Important?
TE.CL smuggling has the same critical impact as CL.TE: security bypass, credential theft, cache poisoning, and request hijacking. Different server combinations are vulnerable to each variant. Testing for both variants is essential as organizations often don't know which parsing method their infrastructure uses.
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 TE.CL differ from CL.TE?
In TE.CL, the front-end reads the chunked body (ending at 0 ), but the back-end uses Content-Length and reads fewer bytes. The remaining data becomes the smuggled request prefix. The mechanics differ but the impact is equivalent.
When is TE.CL more likely than CL.TE?
TE.CL is more common when: back-end servers are older (prefer CL), front-end is a modern CDN or proxy (prefer TE), or reverse proxies add chunked encoding. The specific vulnerability depends on the server software and configuration combination.
What makes TE.CL exploitation different?
TE.CL payload construction differs: you need to craft chunk sizes and positions so the front-end sees a complete chunked request while the back-end's Content-Length reading leaves smuggled content. The math is different but the concept is the same.
How do I protect against TE.CL attacks?
Same principles as CL.TE: use HTTP/2 throughout, normalize requests at the edge, reject requests with both headers, ensure consistent parsing across all tiers, and consider using a single proxy/server software stack to eliminate parsing discrepancies.
Related Scanners
Ready to secure your application?
Start testing for request smuggling - te.cl vulnerabilities today.
Get Started Free