HTTP Request Smuggling: Proxy Desync and Prevention

HTTP request smuggling happens when a front-end proxy and a back-end server disagree about where one HTTP request ends and the next begins, so part of one request is treated as the start of another. It is a weakness of architecture rather than of a single product: every component can look correct in isolation while the chain as a whole is exploitable. The consequences reach beyond one user, because a desynchronised connection is often shared by many users. This guide explains the mechanism at concept level, where it appears in modern stacks, how to detect it and, above all, how to design a chain of proxies, CDNs, load balancers and application servers that parses messages consistently. It is written for application security engineers, platform teams and architects who own reverse proxies and edge services. It contains no request examples or payloads.

Key takeaways

It is a parsing disagreement, not an input bug. MITRE classes it as CWE-444, inconsistent interpretation of HTTP requests by an intermediary and the server behind it.
HTTP/1.1 framing is the root cause. Message length can be signalled by Content-Length or by chunked Transfer-Encoding, and RFC 9112 Section 6.3 sets strict rules for when both appear or a value is invalid.
HTTP/2 end to end removes the classic ambiguity. Downgrading HTTP/2 to HTTP/1.1 at the edge reintroduces it and is a common source of newer variants.
Reject, do not repair. Every hop should reject ambiguous messages and close the connection, as RFC 9112 and OWASP ASVS 5.0 requirement V4.2.1 expect, rather than guessing which length to trust.
Treat the chain as one system. Inventory every hop, align parser settings, test the whole path and patch intermediaries as fast as internet-facing servers.

How the attack works

An HTTP/1.1 connection carries a stream of bytes. Each recipient must decide how many of those bytes belong to the current message before it can read the next one. RFC 9112 defines two ways to do that for a request body: a Content-Length header giving a byte count, or Transfer-Encoding: chunked, where the body is sent in length-prefixed pieces ending with a zero-length chunk. The specification also keeps legacy rules for messages without either. When a message carries signals that two implementations resolve differently, they split the stream at different points.

Front end and back end: the front end (CDN, WAF, load balancer or reverse proxy) parses the request one way and forwards it. The back end parses the same bytes another way and believes a second, partial request has begun.
Connection reuse: proxies keep pooled, persistent connections to back ends and send requests from many users over them. Bytes left over from one user's message can be joined to the next user's request on that connection. That is why the impact is cross-user.
Variant names: researchers name variants by which hop honours which signal, for example CL.TE, TE.CL and TE.TE for HTTP/1.1 chains, CL.0 or 0.CL where one side ignores a body entirely, and H2.CL or H2.TE where an HTTP/2 front end converts requests to HTTP/1.1.
Response-side desync: the same class of flaw can affect responses, where a proxy and server disagree about response length. MITRE CAPEC lists this separately as CAPEC-273, HTTP Response Smuggling, alongside CAPEC-33, HTTP Request Smuggling.

What the standards now require

Situation	Required behaviour	Source
Request has both Content-Length and Transfer-Encoding	Transfer-Encoding overrides Content-Length; the message ought to be handled as an error; a server may reject it and must close the connection after responding	RFC 9112 Sections 6.1 and 6.3
Intermediary forwards such a message	Must remove the received Content-Length and process the Transfer-Encoding before forwarding	RFC 9112 Section 6.3
Invalid Content-Length on a request	Unrecoverable error: respond 400 Bad Request and close the connection (a list of identical valid values is the only tolerated exception)	RFC 9112 Section 6.3
Invalid Content-Length on a response at a proxy	Close the connection to the server, discard the response and return 502 to the client	RFC 9112 Section 6.3
Message boundaries at every component	Load balancers, firewalls and application servers determine boundaries using the mechanism appropriate to the HTTP version	OWASP ASVS 5.0 V4.2.1
Generated messages	Content-Length must not conflict with the length determined by protocol framing	OWASP ASVS 5.0 V4.2.2
HTTP/2 and HTTP/3	Do not send or accept connection-specific fields such as Transfer-Encoding; reject CR, LF or CRLF in field names and values	OWASP ASVS 5.0 V4.2.3 and V4.2.4

RFC 9112 Section 11.2 states that these framing rules were tightened specifically to reduce the effectiveness of smuggling. Software that predates them, or that offers a lenient mode for compatibility, is where the risk concentrates.

Where it shows up

Any deployment with two or more HTTP parsers in series is a candidate.

Architecture	Why desync is possible	Typical owner
CDN in front of an origin load balancer and application server	Three or more parsers from different vendors, often with different HTTP versions per hop	Platform or edge team
HTTP/2 or HTTP/3 at the edge, HTTP/1.1 to the origin	The edge rewrites binary-framed requests into text framing; a lenient translation can produce an ambiguous HTTP/1.1 message	Edge and application teams jointly
Cloud load balancer in front of containers or functions	Managed front end, application framework parser behind it (for example a language runtime's built-in HTTP server)	Cloud platform team
Web application firewall or API gateway inline	The security control may inspect a different request from the one the back end executes	Security engineering
Enterprise application platforms with their own dispatchers	Proprietary web dispatchers and application servers, often patched on slow cycles	ERP or application operations
Service mesh sidecars and internal ingress	East-west traffic passes several proxies that are rarely tested for framing consistency	Platform team

Known exploited cases: CISA's Known Exploited Vulnerabilities catalog lists CVE-2022-22536, a request smuggling flaw in SAP NetWeaver Application Server ABAP and Java, ABAP Platform, SAP Content Server and SAP Web Dispatcher, added in August 2022. CISA's description notes it let an unauthenticated attacker prepend data to a victim's request or poison intermediary web caches.
Framework parsers: CWE-444 lists observed examples such as CVE-2020-8287 in Node.js, where duplicate Transfer-Encoding headers allowed smuggling. Language runtimes and frameworks are back ends too, and need the same patch discipline as proxies.
Scope boundary: "smuggling" is also used for unrelated techniques, such as HTML or SVG smuggling of files in phishing, and SMTP smuggling in email. Those are covered elsewhere. See the Phishing Guide.

Impact

Impact	How it arises	Who is affected
Bypass of front-end security controls	The WAF, gateway or path-based access rule evaluates one request while the back end runs another that the front end never saw	The application owner; internal or admin paths exposed
Capture of other users' requests	Another user's request, including its session cookie or bearer token, is appended to attacker-controlled content and stored or reflected	Any user sharing the connection pool
Response queue poisoning	Responses are delivered to the wrong clients once the connection is desynchronised	Random users, which makes incidents hard to reproduce
Web cache poisoning	A harmful response is stored by a shared cache against a legitimate URL, as CWE-444 notes	Every user who requests that URL until the entry expires
Amplified client-side attacks	Reflected input that would need user interaction can be delivered to unsuspecting users	End users

The identity angle is direct: smuggling is a way to steal session cookies, OAuth bearer tokens and API keys in transit between a proxy and an application, without touching the identity provider. Short token lifetimes and sender-constrained tokens limit what a captured credential is worth. See the Session Hijacking and Cookie Theft Guide.

Detection

Smuggling is hard to see in application logs because the back end records what it believed it received. Detection relies on the components that see the raw message and on mismatches between hops.

Front-end anomaly classification: AWS Application Load Balancer classifies every request as Compliant, Acceptable, Ambiguous or Severe, records the classification and a reason code in access logs, and increments the CloudWatch metric DesyncMitigationMode_NonCompliant_Request_Count for requests that do not comply with the HTTP/1.1 specification.
Rejection telemetry: count 400 responses generated by proxies and servers for framing errors. Apache HTTP Server, for example, returns 400 for grammar violations in its default strict mode; its documentation suggests reviewing unexpected 400s in the access log and debug-level error logs.
Request count mismatches: compare per-connection request counts and request IDs at the front end against the back end. More requests logged at the origin than forwarded by the edge is a strong desync indicator.
Odd response routing: reports of seeing another user's page, or intermittent errors on valid requests, suggest response queue poisoning.
Security testing: include desync checks in authorised DAST and penetration tests of the full production-like path, not only the application in isolation. See the Web Application Security Testing Guide.

Metrics that show the controls work

Percentage of internet-facing HTTP paths where every hop runs a strict parsing mode (target: 100%).
Percentage of edge-to-origin hops using HTTP/2 or newer end to end.
Non-compliant or ambiguous request rate at the edge, trended weekly, with alerts on sudden rises.
Median days to patch a proxy, load balancer or HTTP framework CVE tagged CWE-444, measured against the KEV due date where one applies.
Number of hops with lenient or legacy parsing options enabled, each with an owner and expiry date.

Prevention and hardening

The objective is that every hop either agrees on message boundaries or refuses the message. Defences in order of strength:

Control	What it achieves	Trade-off
HTTP/2 or HTTP/3 end to end, from client to origin	Removes text-based length ambiguity because each frame carries its own length	Back-end support, connection handling changes, testing effort
Strict parsing at every hop, ambiguous messages rejected and connection closed	Directly implements RFC 9112 Section 6.3 and ASVS V4.2.1	Some legacy clients may be refused; requires monitoring before enforcement
Normalise at the edge: regenerate a clean request rather than forwarding the original bytes	Back ends only ever see one unambiguous framing	Depends on the edge product's capability
Single vendor or single parser library across the chain	Fewer parsing differences to reason about	Rarely achievable with CDNs and managed services
Disable back-end connection reuse	Limits leftovers to the attacker's own connection; CWE-444 lists ending the session after each request as a mitigation	Higher latency and connection cost; a fallback, not a target state
WAF signatures for malformed framing	Blocks known patterns	The WAF is itself a parser in the chain; useful only alongside strict parsing

Product settings worth knowing

AWS Application Load Balancer: attribute routing.http.desync_mitigation_mode with values monitor, defensive (default) and strictest. Defensive blocks Severe requests and closes connections on Ambiguous ones; strictest blocks anything that is not Compliant. AWS notes that a high rate of Ambiguous requests in defensive mode increases new connections, so compare NewConnectionCount when changing modes.
Apache HTTP Server: HttpProtocolOptions defaults to Strict LenientMethods Allow0.9. Keep Strict on any public server (the documentation cautions strongly against Unsafe) and consider Require1.0 to reject HTTP/0.9 requests.
NGINX: proxy_http_version defaults to 1.1 from version 1.29.7 (1.0 before), and value 2 is supported from 1.29.4 with the HTTP/2 module, which enables HTTP/2 to upstreams.
HAProxy: by default rejects HTTP/1.0 GET, HEAD and DELETE requests that carry a body, because inconsistent handling of such payloads makes smuggling possible. Leave compatibility options that relax this off unless a specific client needs them.

Phased rollout

Inventory the path. For each internet-facing hostname, list every hop (CDN, WAF, load balancer, ingress, sidecar, framework server), its product and version, the HTTP version on each side, and whether back-end connections are pooled.
Patch first. Bring every proxy, load balancer and HTTP framework to a version that implements RFC 9112 framing rules. Prioritise anything in CISA KEV.
Monitor mode. Switch on anomaly classification or strict-mode logging without blocking (for example ALB monitor mode) for two to four weeks and review which clients send non-compliant requests.
Enforce in rings. Move a low-risk hostname to strict or defensive enforcement, then wider rings. Roll back by returning the attribute or directive to the previous value, which takes effect without redeploying applications.
Move towards HTTP/2 to origin. Where the CDN, load balancer and back end support it, enable HTTP/2 upstream and retire HTTP/1.1 downgrade paths.
Test the whole chain. Run authorised desync tests after every change to proxy products, versions or routing, and add them to release gates for edge configuration.

Decision guidance

Small organisations on a single managed CDN or cloud load balancer: rely on the provider's strictest compatible mode, keep frameworks patched and avoid adding a second self-managed proxy unless needed.
Large organisations with multi-vendor edges: set a platform standard for parser settings, require HTTP/2 to origin for new services, and assign one team ownership of the whole request path.
Strict versus defensive: choose the strictest mode for APIs and authenticated applications with known clients; use defensive mode where legacy or embedded clients send slightly non-compliant traffic, and track exceptions.

Inline protection products are covered in more depth in the Web Application Firewall Guide, and the wider family of web attacks in the Web Application Attacks Guide.

Framework mapping

Framework	Reference	Relevance
MITRE CWE	CWE-444	The weakness itself
MITRE CAPEC	CAPEC-33, CAPEC-273	Request and response smuggling attack patterns
MITRE ATT&CK	T1190 Exploit Public-Facing Application	How smuggling is used for initial access
OWASP ASVS 5.0	V4.2.1, V4.2.2, V4.2.3, V4.2.4	Verification requirements for HTTP message structure
NIST SP 800-53 Rev. 5	SI-10, SC-7, CM-6, SA-11, SI-4	Input validation, boundary protection, secure configuration, developer testing, monitoring
NIST CSF 2.0	PR.PS-01, DE.CM-01	Configuration management; monitoring of networks and network services

Practitioner checklist

Map every hop on each public request path, with product, version and HTTP version per side.
Patch proxies, load balancers and HTTP frameworks for CWE-444 issues on the same cycle as internet-facing servers.
Configure every hop to reject messages with conflicting or invalid length signals and close the connection.
Run strict parsing modes (for example Apache HttpProtocolOptions Strict, ALB defensive or strictest) and record any exception with an owner and expiry.
Prefer HTTP/2 end to end and remove HTTP/2 to HTTP/1.1 downgrades where the back end supports HTTP/2.
Forward normalised requests from the edge rather than raw client bytes where the product allows.
Alert on non-compliant request rates and on request-count mismatches between front end and back end.
Mark authenticated responses non-cacheable so a desync cannot be turned into cache poisoning.
Include full-chain desync testing in authorised penetration tests and in change gates for edge configuration.

Standards and references

Related NHI Mgmt Group resources: Web Application Attacks Guide · Web Application Firewall Guide · Edge Device Security Guide · API Security Guide

HTTP Request Smuggling Guide: Proxy Desync Risks and Prevention