📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🎯 BUG BOUNTY MASTERY
FREE
Part of the Bug Bounty Mastery Course
Day 21 of 180 · 12% complete
⚠️ Authorised Targets Only. HTTP request smuggling against a live target can affect other users on the same back-end connection pool. All exercises in this lesson must be performed exclusively on PortSwigger Web Security Academy labs or your own authorised test applications. Never test request smuggling against production targets without explicit written permission from the application owner — the impact can extend beyond your own session to other users’ traffic.
HTTP Request Smuggling in 2026 :— James Kettle called it “reborn” in 2019 when he showed how a single ambiguous HTTP request could poison another user’s connection. Six years later, the vulnerability class has evolved — HTTP/2 downgrade attacks created new variants — but the core condition remains widespread: front-end load balancers and back-end origin servers parsing the same request differently, creating a gap where hidden requests can slip through every perimeter defence. It bypasses authentication, captures other users’ credentials, and poisons CDN caches at scale. It is one of the highest-severity and highest-paying vulnerability classes in modern web bug bounty, and it sits in almost every application running HTTP/1.1 between layers.
🎯 What You’ll Master Today
Understand the CL/TE desync condition that makes request smuggling possible
Distinguish CL.TE vs TE.CL attack types and know which to test first for each target
Detect smuggling vulnerabilities safely using Burp’s HTTP Request Smuggler extension
Exploit for access control bypass — reaching admin endpoints the front-end blocks
Exploit for credential capture — poisoning connections to receive another user’s request
Write a complete bug bounty report for a confirmed smuggling finding
⏱️ 60 min · 3 exercises · Burp Suite + PortSwigger labs #### 📋 Prerequisites — Complete Before Day 21 - Day 12: File Upload Bug Bounty — intermediate HTTP manipulation skills needed before tackling the complex header interactions in request smuggling - Day 18: OAuth Attacks — understand multi-layer auth flows; smuggling exploits the same front-end/back-end trust relationships that OAuth attacks target - Burp Suite installed and configured as browser proxy — all exercises require active Burp Proxy interception ### 📋 HTTP Request Smuggling 2026 — Contents 1. How HTTP Request Smuggling Works — The Desync Condition 2. CL.TE Attack — Front-End Uses Content-Length 3. TE.CL Attack — Front-End Uses Transfer-Encoding 4. Detection with Burp HTTP Request Smuggler 5. High-Impact Exploitation Scenarios 6. HTTP/2 Downgrade Smuggling — 2026 Variants 7. Reporting and Remediation ## How HTTP Request Smuggling Works — The Desync Condition Modern web applications typically use a front-end server — a CDN, reverse proxy, or load balancer — that forwards requests to back-end origin servers. HTTP/1.1 allows multiple requests over a single TCP connection (keep-alive). When the front-end forwards these requests to the back-end, it needs to correctly determine where one request ends and the next begins. HTTP/1.1 specifies two headers for this purpose: Content-Length (specifying the exact byte count of the body) and Transfer-Encoding: chunked (specifying body length through a series of chunks with hexadecimal length prefixes).
The specification says both headers should never appear in the same request. When they do, different servers make different decisions about which to honour. If the front-end and back-end make different decisions — one honours Content-Length, the other honours Transfer-Encoding — they disagree about where the request body ends. The bytes the front-end includes as part of the first request body may be interpreted by the back-end as the beginning of a second request. That second request was smuggled in without going through the front-end’s security checks.
securityelites.com
CL.TE Desync — How One Request Becomes Two
FRONT-END sees (uses Content-Length: 13)
POST / HTTP/1.1
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
Forwards all 13 bytes as one request body
BACK-END sees (uses Transfer-Encoding)
Request 1:
POST / HTTP/1.1
body: [chunk “0\r\n\r\n” = empty]
Request 2 (smuggled):
SMUGGLED ← next user’s request appended
Treats “SMUGGLED” as start of new request
📸 The CL.TE desync condition. The front-end honours Content-Length and sees a single 13-byte request body. The back-end honours Transfer-Encoding and sees the chunk terminator (0\r\n\r\n) as the end of the request, then interprets “SMUGGLED” as the beginning of a new request. The smuggled data is prepended to the next user’s incoming request — poisoning it with attacker-controlled content before it reaches the application.
CL.TE Attack — Front-End Uses Content-Length
In a CL.TE attack, the front-end uses the Content-Length header to determine the body size and forwards the entire CL-length body to the back-end. The back-end uses Transfer-Encoding and processes the chunked body — reading each chunk and its hex length prefix until it encounters the zero-length terminator chunk (0\r\n\r\n). Any bytes after the terminator that were included in the CL-sized body are left in the back-end’s read buffer and treated as the beginning of the next request.
The attack payload places a zero-length chunk terminator early in the body, followed by the smuggled request prefix. The front-end reads the full CL-sized body and forwards all of it. The back-end reads up to the zero-length chunk and stops, leaving the smuggled prefix in its buffer. When the next request arrives from any user, the back-end prepends the buffered smuggled prefix to that request — resulting in a malformed request that may reach different application logic or expose the next user’s request to the attacker.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)