HTTP Request Smuggling: Detection, Attack Techniques, and Defense
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
HTTP request smuggling is a server-side vulnerability that exploits a design ambiguity in HTTP/1.1: when both Content-Length and Transfer-Encoding headers are present in a request, different servers may use different rules to determine which takes priority. A frontend proxy that prioritizes Content-Length will forward what it considers a complete request; if the backend prioritizes Transfer-Encoding and processes a shorter chunked body, the remainder sits in the backend's buffer, ready to be prepended to the next request from any user.
This vulnerability is infrastructure-level rather than application-level: it cannot be fixed in application code alone, and it affects the security of all users who share the same backend connection pool. The attack was extensively researched and documented by James Kettle at PortSwigger, who demonstrated that major internet services including web caches, CDNs, and application load balancers were vulnerable.
How CL.TE smuggling works
The CL.TE variant is the most frequently observed in real-world environments because many reverse proxy and CDN configurations prioritize Content-Length at the ingress while backend application servers prefer chunked transfer encoding. Walking through the attack step by step reveals exactly why the vulnerability is difficult to detect through normal monitoring: the attacker's request looks syntactically valid at both the proxy and the backend in isolation, and the poisoning effect only becomes visible when a second legitimate request arrives on the same backend connection. Understanding this timing dependency is also necessary for correctly interpreting Burp Suite's timing-based detection probes and for explaining to infrastructure teams why the fix must happen at the connection layer rather than the application layer.
Step 1: The attacker crafts a request with both headers
The attacker sends a POST request with both Content-Length and Transfer-Encoding: chunked headers. The Content-Length value is large, encompassing the entire body including a partial HTTP request prefix. The chunked body terminates early with a zero-length chunk. Example: POST / HTTP/1.1\r\nHost: vulnerable.com\r\nContent-Length: 49\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /admin HTTP/1.1\r\nHost: vulnerable.com\r\n. The frontend sees Content-Length: 49 and forwards the entire body. The backend sees Transfer-Encoding: chunked, processes the 0-length chunk (empty body), and leaves 'GET /admin HTTP/1.1\r\nHost: vulnerable.com\r\n' queued in its buffer.
Step 2: The next legitimate request is appended to the smuggled prefix
When the next user (or the attacker themselves) sends a request to the same backend server process, the backend prepends the queued 'GET /admin HTTP/1.1' prefix to that request's headers. The combined request bypasses any frontend access control that restricted /admin access, because the backend processes the smuggled request independently of the original frontend routing. The victim user may receive an unexpected response (the /admin response instead of what they requested), or the attacker's prefix may capture the victim's request content (cookies, tokens, body) if the prefix creates a request where the victim's subsequent headers are included as the body.
Session hijacking via request capture
To capture other users' session tokens: the attacker's smuggled prefix is designed to submit a POST request to an endpoint that stores or reflects request data (a search endpoint, comment submission, or profile update). The smuggled prefix includes a large Content-Length that forces the backend to consume the next request's headers as the body of the smuggled POST. The attacker polls the storage endpoint and reads the victim's Cookie header (and any other request headers) that were captured as the body of the attacker's smuggled POST request. This hijacks the victim's session without XSS or phishing.
Detection methodology
Request smuggling detection requires a different approach than most vulnerability classes because a naive active test can accidentally poison legitimate users' requests on a shared production backend. The recommended workflow is to start with timing-based probes that confirm parsing discrepancies without actually queuing a malicious prefix, then move to confirmation probes only in isolated test environments or low-traffic maintenance windows. Burp Suite's HTTP Request Smuggler extension automates the timing probes and selects the correct variant to test based on initial probe responses, making it the practical starting point for most assessments. The infrastructure audit checklist in the third item below should run in parallel with dynamic testing, since some configurations are vulnerable in ways that timing probes may not detect under normal load conditions.
Automated detection with Burp Suite HTTP Request Smuggler
Install the HTTP Request Smuggler extension in Burp Suite. Right-click any request and select 'Smuggle probe' to automatically test for CL.TE, TE.CL, and HTTP/2 downgrade variants. The extension uses timing-based detection: it sends a probe that will cause the backend to wait if vulnerable (receiving a partial chunked request), and measures whether the response is delayed relative to a baseline. A delay of 5-10 seconds indicates backend desynchronization. The extension also supports confirmation probes that verify exploitability without visibly affecting other requests.
Manual timing-based detection for CL.TE
Send a request with Transfer-Encoding: chunked and Content-Length set to a value larger than the actual chunked body. If the backend prioritizes Content-Length but processes chunked encoding, it waits for additional bytes to satisfy Content-Length after the chunked body ends, causing a timeout. Include the Connection: close header to prevent connection reuse during testing. Compare response times against a baseline non-chunked request to the same endpoint. A consistent 5+ second delay that is not present in the baseline strongly indicates CL.TE vulnerability. Use a dedicated test account and avoid testing endpoints that modify state or queue work.
Infrastructure-level audit
Request smuggling is primarily an infrastructure problem. Audit your load balancer and reverse proxy configuration for: explicit Transfer-Encoding header handling (how does your nginx/HAProxy/Cloudflare configuration handle requests with both CL and TE?), HTTP version between proxy and backend (HTTP/1.1 with keep-alive connections is the risk surface; HTTP/2 eliminates it), and shared backend connection pools (request smuggling affects shared connections, so single-tenant dedicated connections reduce exposure). Review your CDN provider's documentation on request normalization and whether they normalize or block conflicting CL/TE headers.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Remediation at the infrastructure level
Unlike most web vulnerabilities, HTTP request smuggling cannot be addressed through application-layer input validation or output encoding; the root cause lives in the HTTP parsing layer of your proxy and backend server infrastructure. The primary fix is a protocol upgrade that removes the ambiguous header interpretation entirely by switching to HTTP/2 for the frontend-to-backend connection. When that upgrade is not immediately feasible, the secondary approach is configuration hardening at the proxy layer to reject or normalize ambiguous requests before they reach the backend. Both approaches require changes to infrastructure configuration files rather than application code, which means the fix typically goes through infrastructure or platform engineering teams and benefits from runbook documentation that explains the exact configuration directives to change for each proxy technology in use.
Primary fix: HTTP/2 end-to-end
Configure the backend connection from your frontend proxy to your application server to use HTTP/2. HTTP/2 uses binary framing with explicit stream boundaries and does not use Content-Length or Transfer-Encoding for message delimitation. This eliminates the CL/TE ambiguity that enables smuggling. In nginx: use the http2 flag on proxy_pass upstream connections if the upstream supports HTTP/2. In AWS Application Load Balancer: enable HTTP/2 on the target group. Verify that your application server (Tomcat, Gunicorn, uWSGI) supports HTTP/2 upstream connections before enabling.
Secondary fix: reject or normalize ambiguous requests
If HTTP/2 is not feasible for the backend connection: configure the frontend to reject any request containing both Content-Length and Transfer-Encoding (return 400 Bad Request). In nginx: use the map module to detect and block requests with both headers. In HAProxy: use http-request reject if both headers are present. For Cloudflare WAF: the 'HTTP anomaly' detection rule blocks requests with both headers by default in high-sensitivity mode. Normalizing the headers (dropping Content-Length when Transfer-Encoding is present, per RFC 7230) is also acceptable if rejection is not possible.
The bottom line
HTTP request smuggling is an infrastructure-level vulnerability with infrastructure-level remediation. Application code changes do not fix it. The path to elimination is: migrate frontend-to-backend communication to HTTP/2, or configure both proxy and backend to enforce the same header priority rules and reject ambiguous requests. Use Burp Suite's HTTP Request Smuggler extension to test your endpoints, focus on any infrastructure where a different reverse proxy, CDN, or load balancer sits in front of your application servers, and verify that your CDN provider normalizes conflicting CL/TE headers before they reach your origin.
Frequently asked questions
What is HTTP request smuggling?
HTTP request smuggling occurs when a frontend proxy and backend server parse HTTP message boundaries differently. In HTTP/1.1, two headers define message length: Content-Length (byte count) and Transfer-Encoding: chunked (chunk-based). When both are present, RFC 7230 says Transfer-Encoding takes priority and Content-Length should be ignored. If the frontend and backend disagree on which header to prioritize, the frontend forwards what it considers a complete request, but the backend processes only part of it, leaving the remainder to be prepended to the next request from any user.
What is the difference between CL.TE and TE.CL smuggling?
CL.TE: the frontend uses Content-Length and the backend uses Transfer-Encoding. The attacker sends a request with both headers, where Content-Length is large and Transfer-Encoding terminates the chunked body early. The frontend forwards the full Content-Length bytes; the backend processes the chunked body (shorter) and leaves the remainder queued as the start of the next request. TE.CL: the reverse, where the frontend uses Transfer-Encoding and the backend uses Content-Length. The attacker sends a chunked request where the backend's Content-Length reading causes it to consume into the next request.
What attacks can be performed via request smuggling?
Bypassing front-end security controls: the smuggled prefix bypasses WAF, authentication, or IP restriction rules enforced at the frontend but not the backend. Session hijacking: the smuggled prefix captures other users' requests by prepending a partial request that causes their subsequent headers and body (including cookies) to be appended to attacker-controlled request data, which the backend may reflect or log. Reflected XSS via request smuggling: injecting XSS payloads into smuggled requests that are reflected in other users' responses. Web cache poisoning: poisoning the cache to serve attacker-controlled responses to all subsequent requests for a cached resource.
How do I detect HTTP request smuggling?
Burp Suite Pro's HTTP Request Smuggler extension (or the built-in scanner in Burp Suite Enterprise) sends CL.TE and TE.CL detection payloads and measures timing differentials or response anomalies that indicate smuggling. The timing-based technique: a CL.TE probe sends a request where a correct CL.TE-prioritizing server returns a normal response, but a vulnerable backend pauses waiting for the remainder of the smuggled chunk, causing a detectable timing delay. Manual testing involves sending crafted requests with conflicting headers and observing response time or unexpected responses. Test from an isolated environment to avoid accidentally poisoning other users' requests during testing.
How do I fix HTTP request smuggling?
Upgrade the frontend-backend communication to HTTP/2 end-to-end. HTTP/2 has a single, unambiguous framing mechanism that eliminates the CL/TE ambiguity. If HTTP/1.1 must be used on the backend connection: configure both the frontend and backend to reject requests that contain both Content-Length and Transfer-Encoding headers (dropping them rather than forwarding); configure the backend to normalize Transfer-Encoding headers before processing; and use the same web server software for both frontend and backend to eliminate parsing discrepancies. For load balancer configurations, set the backend connection to use HTTP/2 or ensure strict request normalization at the ingress.
Does a WAF protect against request smuggling?
A WAF positioned at the frontend is typically the attack surface for request smuggling, not a protection layer, because the smuggled content is already past the WAF when it reaches the backend. WAFs may help if they normalize ambiguous headers before forwarding, but many do not. The effective fix is at the infrastructure level: eliminating the parsing discrepancy between frontend and backend, not adding another intermediary. Some WAFs (Cloudflare, for example) have added specific request smuggling normalization, but verify that the specific WAF you use applies this to your traffic before relying on it.
What is HTTP/2 request smuggling?
HTTP/2 request smuggling (H2.CL and H2.TE) exploits the downgrade from HTTP/2 (used between client and frontend) to HTTP/1.1 (used between frontend and backend). HTTP/2 does not use Content-Length or chunked encoding for framing, but the frontend may rewrite HTTP/2 requests into HTTP/1.1 by adding Content-Length headers. If the frontend adds a Content-Length that the attacker can influence (for example, by including a content-length pseudo-header in an HTTP/2 request that overrides the automatically computed value), the frontend may forward a request with a misleading Content-Length to the HTTP/1.1 backend, creating smuggling conditions.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.