Community hub
0 subscribers8 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to HTTP request smuggling.
Nothing was collected or created yet.
HTTP request smuggling
View on Wikipediafrom Wikipedia
| HTTP |
|---|
 |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
HTTP request smuggling (HRS) is a security exploit on the HTTP protocol that takes advantage of an inconsistency between the interpretation of Content-Length and Transfer-Encoding headers between HTTP server implementations in a HTTP proxy server chain.[1][2]
The Transfer-Encoding header works by defining a directive on how to interpret the body of the HTTP request, with the common and necessary directive for this attack being the chunked transfer encoding.[3] When the Transfer-Encoding header is present, the Content-Length header is supposed to be omitted.[3] Working similarly but with a different syntax, the Content-Length header works by specifying the size in bytes of the body as a value in the header itself.[4] Vulnerabilities arise when both of these headers are included in a malicious HTTP request, bypassing security functions meant to prevent malicious HTTP queries to the server by causing either the front-end or back-end server to incorrectly interpret the request.[5]
Types
[edit]CL.TE
[edit]In this type of HTTP request smuggling, the front end processes the request using Content-Length header while backend processes the request using Transfer-Encoding header.[2] The attack would be carried out with the first part of the request declaring a zero length chunk.[5] The front end server seeing this would only read the first part of the request and unintentionally pass the second part to the back end server.[5] Once passed through to the back end server, it would be treated as the next request and processed, carrying out the attackers hidden request.[5]
TE.CL
[edit]In this type of HTTP request smuggling, the front end processes request using Transfer-Encoding header while backend processes the request using Content-Length header.[2] In this attack, a hacker would declare the valid length of the first chunk, which houses the malicious request and then declare a second chunk with a length of 0.[5] When the front end server sees the second chunk with a length of 0 it believes the request to be complete and passes it along to the back end server.[5] The back end server processes the request using the Content-Length header, however, and as a result the malicious request left in the first chunk go unprocessed until they are treating as being at the start of next request in the sequence and are carried out.[2]
TE.TE
[edit]In this type of HTTP request smuggling, the front end and backend both process the request using Transfer-Encoding header, but the header can be obfuscated in a way (for example by nonstandard whitespace formatting or duplicate headers) that makes one of the servers but not the other one ignore it.[2] Obscuring the header may take the form of adding in an incorrect character, such as Transfer-Encoding: xchunked, or an unusual new line character between 'Transfer-Encoding' and ': chunked'.[5] If one of the front of back end servers still processes these obfuscated HTTP requests, then the rest of the attack will be similar to how CL.TE or TE.CL attacks work.[5]
Prevention
[edit]The best prevention to these attacks would clearly be if frontend and backend servers interpreted HTTP requests the same way. However, this is usually not an option as load balancers support backend servers run on distinct platforms, using different software.[5] Most variants[specify] of this attack can be prevented by using HTTP/2, as it uses a different method to determine the length of a request. Another method of avoiding the attack is for the frontend server to normalize HTTP requests before passing them to the backend, ensuring that they get interpreted in the same way.[2] Configuring a web application firewall is another good way to prevent HRS attacks as many feature technology that identify attack attempts and either blocks or sanitize the suspicious incoming requests.[5]
Grenfeldt et al. (2021) found that most front-end web servers (e.g. proxy servers) provided the parsing features for hindering in practice, all the known HRS attacks on the back-end web servers.[6] Huang et al. (2022) proposed a method using Flask so to implement suitable parsing features that prevent HRS attacks, from a front-end program or web server.[7]
References
[edit]- ^ "CWE - CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') (4.0)". cwe.mitre.org. Retrieved 2020-03-13.
- ^ a b c d e f "What is HTTP request smuggling? Tutorial & Examples | Web Security Academy". portswigger.net. Retrieved 2020-03-13.
- ^ a b "Transfer-Encoding". developer.mozilla.org. Retrieved 2022-12-15.
- ^ "Content-Length". developer.mozilla.org. Retrieved 2022-12-15.
- ^ a b c d e f g h i j "HTTP Request Smuggling". imperva.com. Retrieved 2022-12-15.
- ^ Grenfeldt M, Olofsson A, Engström V, Lagerström R (2021). "Attacking websites using HTTP request smuggling: empirical testing of servers and proxies". 2021 IEEE 25th international enterprise distributed object computing conference (EDOC). Australia: IEEE. pp. 173–181. doi:10.1109/EDOC52215.2021.00028.
- ^ Huang Q, Chiu M, Chen Y, Sun H (2022). "Attacking websites: detecting and preventing HTTP request smuggling attacks". Security and Communication Networks. 2022: 1–14. doi:10.1155/2022/3121177.
HTTP request smuggling
View on Grokipediafrom Grokipedia
HTTP request smuggling is a high-severity web security vulnerability that exploits discrepancies in how HTTP/1.1 servers and proxies interpret ambiguous request formats, particularly involving the
Here, the front-end reads a body of length 13 (covering
To test differentially, repeat the request but change the smuggled request to target an invalid path (e.g.,
Here, the chunk size "5c" (hexadecimal for 92 bytes) includes the smuggled "GPOST" request, which the back-end processes as a new request after consuming only 4 bytes for the original POST body.[23]
Exploitation in TE.CL attacks enables request injection, where the smuggled request can target internal endpoints, bypass authentication, or interfere with other users' sessions by desynchronizing the request queue.[4] This variant was prevalent in older proxy configurations, such as Microsoft IIS versions that ignored Transfer-Encoding when Content-Length was present, allowing attacks against back-end servers like Tomcat or SunONE when fronted by proxies like Apache 2.0.45.[3]
Historically, TE.CL smuggling was first detailed in 2005 by Watchfire researchers, who demonstrated its impact on early web infrastructure, marking it as a significant vulnerability in the early 2000s before broader awareness of HTTP parsing ambiguities grew.[3]
Here, the front-end sees only the initial POST to
Content-Length and Transfer-Encoding headers, enabling attackers to "smuggle" malicious requests past security controls by desynchronizing the request pipeline between front-end and back-end components.[1] This attack arises in multi-tier architectures where a front-end proxy (such as a load balancer or reverse proxy) and a back-end server disagree on request boundaries, allowing the attacker to craft requests that one component views as a single message while the other interprets as multiple distinct requests.[2]
The vulnerability was first documented in 2005 by researchers at Watchfire, who identified it as a potential issue in HTTP request parsing but noted its complexity limited early exploitation.[3] It gained renewed attention in 2019 through research by James Kettle at PortSwigger, who demonstrated practical exploits against modern web applications and infrastructure, including bypasses of web application firewalls (WAFs) and content delivery networks (CDNs).[4] This resurgence highlighted how evolving HTTP implementations, such as HTTP/2 downgrading to HTTP/1.1, could introduce new desynchronization opportunities.[1] As of 2025, the issue persists with new variants and high-severity vulnerabilities reported in major systems, alongside ongoing research and standardization efforts to mitigate desynchronization risks.[5][6]
HTTP request smuggling exploits often rely on non-RFC-compliant behaviors in HTTP parsing, as outlined in standards like RFC 7230.[7]
Background
HTTP Protocol Basics
HTTP requests are fundamental components of the Hypertext Transfer Protocol (HTTP), which enables communication between clients and servers on the World Wide Web. A typical HTTP request consists of a start line, headers, and an optional body. The start line specifies the method (such as GET or POST), the request target (often the path to a resource), and the HTTP version, formatted asmethod SP request-target SP HTTP-version.[8] Headers follow, providing metadata like the host, user agent, and content details, with field names being case-insensitive.[9] The body, if present, contains data such as form submissions or file uploads, delineated by methods including the Content-Length header or Transfer-Encoding header.[10]
In HTTP architectures, requests often pass through intermediaries before reaching the origin server. Proxies and gateways forward requests from clients to servers, potentially modifying headers or the request target to ensure compatibility, such as using the absolute-form of the target URI.[11] Load balancers, functioning as specialized proxies, distribute incoming requests across multiple origin servers to manage traffic and improve scalability, while origin servers process the requests to generate responses. These intermediaries form a processing pipeline where each component parses and forwards the message, assuming consistent interpretation of the HTTP format.
The HTTP/1.1 message format standardizes this structure for interoperability. It begins with the start line terminated by a carriage return line feed (CRLF), followed by zero or more header fields each ending in CRLF, an empty line (CRLF), and the optional message body.[12] Header fields are structured as field-name ":" OWS field-value OWS, where OWS denotes optional whitespace, and the entire message is transmitted as a stream of octets over a connection.[13] This format, defined in RFC 9112, ensures that parsers can reliably identify components, though variations in implementation can arise.
HTTP request smuggling is a desynchronization attack that exploits differences in how front-end intermediaries (like proxies or load balancers) and back-end origin servers parse the same HTTP message, leading to inconsistent interpretations of request boundaries.[7] By crafting ambiguous requests, attackers can cause the front-end to forward additional malicious content as part of a subsequent legitimate request, or vice versa, disrupting the expected request-response flow between components.[7]
Parsing Ambiguities in HTTP/1.1
The original HTTP/1.1 specification, outlined in RFC 2616 published in 1999, contained several ambiguities in message parsing and body length determination that led to inconsistent implementations across servers and proxies.[14] These issues were addressed in the updated specifications, particularly RFC 7230 in 2014 and consolidated in RFC 9112 in 2022, which clarified message syntax and routing to mitigate risks like desynchronization between chained components.[15] Despite these revisions, legacy systems adhering to the older RFC continued to exhibit divergent behaviors, enabling exploitation through request smuggling techniques.[4] A primary ambiguity arises when both theContent-Length and Transfer-Encoding headers are present in a single request. According to the current HTTP/1.1 specification (RFC 9112), the Transfer-Encoding header—typically specifying chunked encoding—takes precedence, requiring recipients to ignore Content-Length and parse the body based on the transfer coding instead.[16] However, RFC 2616 provided less explicit guidance, leading many older implementations to either reject the request outright, prioritize Content-Length, or mishandle the combination in unpredictable ways.[17] This discrepancy allows attackers to craft requests that one parser interprets as having a fixed-length body while another processes it as variably chunked, desynchronizing the message boundaries.[4]
Parser differences between front-end components, such as load balancers or reverse proxies, and back-end servers exacerbate these ambiguities. Front-end parsers often normalize or strictly enforce header rules to maintain compatibility, while back-end application servers may adopt more lenient approaches, such as tolerating invalid whitespace or malformed chunk extensions in Transfer-Encoding.[4] For instance, a front-end might discard an ambiguously formatted Transfer-Encoding header due to non-standard spacing (e.g., Transfer-Encoding : chunked), falling back to Content-Length, whereas the back-end could recognize and apply the chunked encoding, resulting in offset interpretations of subsequent requests on the shared connection.[9] Such variations in handling invalid or edge-case headers create opportunities for desynchronization without altering the core protocol rules.[4]
Non-standard behaviors further compound these issues, particularly in how servers process multiple values in the Transfer-Encoding header. Some implementations treat comma-separated values like Transfer-Encoding: chunked, identity by applying only the last valid coding (identity, effectively disabling chunking), while others reject the entire header or parse it as a single invalid entry.[4] This inconsistency, not fully anticipated in RFC 2616, allows selective exploitation where a front-end ignores the header due to the unrecognized extension, but a back-end applies chunked encoding, shifting the perceived end of the request body.[18] The current specification (RFC 9112) aims to reduce such risks by mandating rejection of unrecognized transfer codings, though legacy parsers persist in the wild.[19]
Attack Mechanism
Content-Length and Transfer-Encoding Headers
The Content-Length header in HTTP/1.1 specifies the length of the message body in bytes, allowing the recipient to determine when the body ends without relying on connection closure. It is particularly used for requests or responses with fixed-size bodies, such as those in POST or PUT methods, where the value is a decimal number representing the exact byte count. If absent, the server may interpret the body as continuing until the connection closes, which can lead to ambiguities in persistent connections. The Transfer-Encoding header, in contrast, enables the encoding of the message body for transfer purposes, most commonly using the "chunked" value to support dynamic or unknown body lengths. When set to "chunked," the body is divided into chunks, each preceded by its hexadecimal size and terminated by a chunk end marker (CRLF), followed optionally by trailers—key-value pairs providing metadata like content checksums. This mechanism is essential for streaming responses or pipelined requests, as it allows the sender to delimit the body without knowing its total size in advance. According to RFC 7230, if both Content-Length and Transfer-Encoding are present in a message, Transfer-Encoding takes precedence, and the Content-Length value must be ignored to avoid conflicts. However, historical implementations of HTTP servers and proxies have sometimes violated this rule, processing Content-Length even when Transfer-Encoding is specified, due to legacy support for HTTP/1.0 behaviors or incomplete updates to parsing logic. Such non-compliance arises from the evolution of the protocol, where early proxies prioritized Content-Length for compatibility with non-chunked transfers. Edge cases in these headers can further complicate body interpretation. For instance, invalid chunk sizes (e.g., non-hexadecimal values or negative sizes) or malformed trailers may cause parsers to mishandle the body, potentially treating subsequent data as part of the current message. Additionally, multiple instances of either header in a single message—prohibited by the specification but possible due to misconfigurations—can lead to ambiguous delimitations, where the first or last value is selected inconsistently across implementations. These issues highlight the need for robust header normalization in intermediaries.How Smuggling Exploits Parser Differences
HTTP request smuggling exploits inconsistencies in how different HTTP parsers interpret ambiguous requests, particularly in architectures where a front-end server (such as a load balancer or reverse proxy) forwards traffic to a back-end server. These discrepancies often arise from variations in handling headers like Content-Length and Transfer-Encoding, leading to mismatched interpretations of request boundaries.[4][20] In the attack flow, an attacker crafts and sends an ambiguous request containing conflicting header values that the front-end and back-end servers parse differently—for instance, the front-end might ignore or override one header while the back-end honors the other. This causes the front-end to forward the request in a way that misaligns with the back-end's expectations, effectively poisoning the underlying TCP connection. As a result, the back-end processes a "hidden" portion of the request as if it were a separate, legitimate one, or it incorporates prefix or suffix data from subsequent requests into unintended contexts.[1][4] The desynchronization manifests in two primary outcomes: the back-end may interpret extraneous data as a new request, allowing injection of malicious content, or it may prepend or append body fragments from the attacker's request to bodies of following legitimate requests, thereby manipulating their structure. This misalignment persists due to the shared connection state between servers.[20][1] The attack unfolds in distinct stages, beginning with the injection of the smuggling request, which exploits the parser differences to desynchronize the servers without immediate detection. This is typically followed by the transmission of a victim request—a seemingly benign subsequent request from another user—that triggers the poisoning effect, as the back-end applies the desynchronized state to process the victim's input incorrectly.[4][1] A key enabler of these exploits is the persistence feature in HTTP/1.1, which allows multiple requests to be queued and transmitted over a single keep-alive connection. This reuse of connections between front-end and back-end servers heightens vulnerability, as desynchronized boundaries can affect an entire queue of requests rather than isolated ones.[20][4]Types of Attacks
CL.TE Variant
The CL.TE variant of HTTP request smuggling exploits discrepancies in how front-end and back-end servers parse requests containing both aContent-Length header and a Transfer-Encoding: chunked header. In this scenario, the front-end server—often a proxy like nginx that does not support chunked encoding—ignores the Transfer-Encoding header and delimits the request body strictly according to the Content-Length value, forwarding only a short, fixed-length body to the back-end. Conversely, the back-end server—such as Apache, which prioritizes Transfer-Encoding per HTTP/1.1 specifications—interprets the body as chunked, expecting additional chunks and thus consuming extra data from the connection, which may include parts of subsequent requests. This leads to request desynchronization, where the back-end misinterprets the stream and processes smuggled content as legitimate requests.[4][21]
A representative payload for this variant includes both headers in a single request, with the chunked body crafted to end prematurely from the front-end's perspective but extend into smuggled material for the back-end. For instance:
POST /search HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Length: 13
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: bar
POST /search HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Length: 13
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: bar
0\r\n\r\n plus initial characters of the smuggled GET), treating the request as complete and passing it along. The back-end, however, sees the 0 chunk as terminating the POST body early, interpreting the subsequent GET /admin line and headers as a new, prefixed request injected before any legitimate follow-up traffic. This structure relies on the front-end's rejection or stripping of Transfer-Encoding while the back-end honors it, creating the ambiguity.[21][4]
Exploitation of the CL.TE variant enables attackers to prefix malicious requests onto a victim's legitimate ones, allowing bypass of access controls or poisoning of shared resources like caches and response queues. For example, an attacker can smuggle a request to an internal administrative endpoint, such as /admin, causing the back-end to process it out-of-sequence and potentially return sensitive data in the victim's response, or inject cache-poisoning content that affects subsequent users. In demonstrated cases, this has facilitated unauthorized access to monitoring tools or session hijacking by altering redirects to capture credentials. Such attacks are particularly effective in keep-alive connections, where the desynchronized stream persists and amplifies the impact on multiple subsequent requests.[4][22]
This variant is common in architectures where front-end proxies enforce strict header validation or lack chunked encoding support, while back-end application servers fully comply with RFC 2616 parsing rules that prioritize Transfer-Encoding over Content-Length. Notable real-world vulnerabilities have been identified in deployments involving content delivery networks like Akamai and services such as New Relic and PayPal, where mismatched parser behaviors enabled remote exploitation without authentication.[4]
Detection of CL.TE smuggling can be indicated by anomalies in server logs, such as discrepancies between the body lengths reported by the front-end and back-end, or unexpected response delays as the back-end times out waiting for non-existent chunks. These signs often manifest during traffic analysis, revealing incomplete or oversized bodies that do not align with standard request patterns.[4][22]
In practice, CL.TE vulnerabilities can be confirmed by sending crafted requests that smuggle different paths and observing differential responses. A common method, demonstrated in PortSwigger Web Security Academy labs, involves using a payload template where the smuggled request targets a valid path (such as /) in one request and an invalid or non-existent path (such as /hopefully404) in another. If the responses differ based on the smuggled path—for example, returning 200 OK with content for / versus 404 Not Found for /hopefully404—it confirms that the back-end server processes the smuggled request independently, while the front-end does not account for it.[21]
A generalized template payload for such confirmation is:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 5
Transfer-Encoding: chunked
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
0
GET / HTTP/1.1
Host: vulnerable-website.com
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 5
Transfer-Encoding: chunked
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
0
GET / HTTP/1.1
Host: vulnerable-website.com
GET /hopefully404 HTTP/1.1). The Content-Length: 5 covers the terminating 0\r\n\r\n of the chunked body, after which the back-end interprets the following data as a new request. Additional \r\n after the smuggled headers may be needed for request validity in some cases.
TE.CL Variant
The TE.CL variant of HTTP request smuggling occurs when the front-end server prioritizes the Transfer-Encoding header and processes the request using chunked encoding, while the back-end server ignores Transfer-Encoding and instead relies on the Content-Length header to delimit the request body.[4] This discrepancy allows an attacker to craft a request where the smuggled content is interpreted by the back-end as the start of a new, independent request on the same connection.[3] In a typical TE.CL payload, the attacker includes both headers in a POST request, with a small Content-Length value (e.g., 4) and Transfer-Encoding set to chunked, followed by chunked body data that embeds a complete malicious request after a terminating zero-length chunk. The front-end consumes the entire chunked body, forwarding all data—including the smuggled request—to the back-end without alteration. However, the back-end parses only the specified Content-Length bytes as the body of the original request, treating the subsequent bytes (the smuggled request) as a separate incoming request.[4] For example, a basic payload might appear as follows:POST / HTTP/1.1
Host: [example.com](/page/Example.com)
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST /admin HTTP/1.1
Host: [example.com](/page/Example.com)
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
foo=bar
0
POST / HTTP/1.1
Host: [example.com](/page/Example.com)
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST /admin HTTP/1.1
Host: [example.com](/page/Example.com)
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
foo=bar
0
TE.TE Variant
The TE.TE variant of HTTP request smuggling exploits discrepancies in how front-end and back-end servers parse the Transfer-Encoding header when both servers support it but interpret obfuscated or malformed values differently.[1] This variant relies solely on Transfer-Encoding ambiguities, without involving Content-Length headers, and occurs in HTTP/1.1 connections where parser implementations vary in handling non-standard formatting.[2] Payloads in TE.TE attacks typically involve obfuscating the Transfer-Encoding header to cause one server to ignore it while the other processes it as valid chunked encoding. Common structures include multiple Transfer-Encoding headers, such asTransfer-Encoding: xchunked followed by Transfer-Encoding: chunked, or insertions with spacing like Transfer-Encoding : chunked or Transfer-Encoding:[tab]chunked.[1] More advanced obfuscations use line folding, such as X: X[\n]Transfer-Encoding: chunked, which exploits differences in header continuation parsing.[2] These malformed encodings lead to misalignment in determining the end of the request body, allowing subsequent data to be interpreted as a separate request by the back-end server.[24]
Exploitation proceeds by crafting a request where the front-end server discards the obfuscated Transfer-Encoding, treating the body as non-chunked and forwarding extra data, while the back-end server recognizes the chunked encoding and processes the trailing content as a new HTTP request.[1] This misalignment enables smuggling via chunk trailers or appended data, potentially injecting malicious requests that bypass the front-end's validation.[24] For instance, an attacker might append a smuggled GET /admin request after the initial POST body, which the back-end executes independently.[2]
A notable example involves the obsolete "identity" value in Transfer-Encoding, deprecated by RFC 7230 but still honored by some implementations like Apache Tomcat, creating parser disagreements with stricter proxies.[25] In such cases, a payload like Transfer-Encoding: identity, chunked causes Tomcat to process it as chunked while upstream servers ignore "identity" and reject the header, smuggling requests through the discrepancy (as seen in CVE-2021-33037).[25][26]
TE.TE attacks are relatively rare compared to mixed variants, primarily affecting custom or legacy server implementations that support Transfer-Encoding but differ in validation strictness.[27] Empirical studies of open-source proxies and servers found that while most modern proxies enforce strict parsing, certain back-end servers exhibit vulnerabilities to TE obfuscations, enabling full smuggling in about 50% of tested configurations involving non-standard TE values.[27] This variant requires both endpoints to support Transfer-Encoding but interpret ambiguities inconsistently, limiting its prevalence to heterogeneous HTTP/1.1 deployments.[1]
Security Impacts
Bypassing Security Controls
HTTP request smuggling enables attackers to evade web application firewalls (WAFs) by exploiting parsing discrepancies between front-end and back-end servers, allowing malicious payloads to be hidden within seemingly benign requests that the front-end processes normally while the back-end interprets them differently.[4] For instance, in a CL.TE attack, the front-end may ignore theTransfer-Encoding header and use Content-Length to parse the request as complete, forwarding the remaining smuggled content to the back-end, which then executes it without WAF inspection.[28] This technique has been demonstrated to bypass WAFs like Akamai on platforms such as PayPal, where line-wrapped headers tricked the front-end into misparsing.[29]
Attackers can also bypass authentication mechanisms by injecting smuggled requests that impersonate authorized users, often exploiting session fixation or internal API headers to gain elevated privileges.[28] In one case, smuggling a request with a forged X-SSL-CLIENT-CN: administrator header allowed access to protected endpoints as if from a legitimate admin session.[28] Similarly, desync attacks have enabled authentication hijacking by processing malicious requests in the context of another user's session, such as stealing Trello authentication cookies via a smuggled POST to a profile endpoint.[25]
Rate limiting can be circumvented by queuing multiple smuggled requests within a single connection, overwhelming backend processing without triggering front-end thresholds that monitor individual requests.[28] This allows attackers to amplify the impact on targeted resources, as the back-end treats the bundled requests as separate and rapid, evading per-IP or per-endpoint limits enforced upstream.[25]
A specific example involves smuggling a POST request to alter administrative actions without direct access, such as in a vulnerable setup where an attacker sends:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
Transfer-Encoding: chunked
0
POST /admin/delete-user HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
userId=12345
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
Transfer-Encoding: chunked
0
POST /admin/delete-user HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
userId=12345
/search with zero-length body due to Content-Length: 11 (adjusted for prefix), but the back-end processes the smuggled POST to /admin/delete-user, enabling unauthorized user deletion.[30] This mirrors real-world exploits, like gaining New Relic admin access via a smuggled POST to an internal session API with the header Service-Gateway-Is-Newrelic-Admin: true.[29]
Potential Attack Outcomes
Successful HTTP request smuggling attacks can lead to severe security breaches by exploiting desynchronization between front-end and back-end servers, resulting in unintended processing of malicious requests. One primary outcome is cache poisoning, where attackers inject falsified responses into shared web caches, causing them to serve malicious content to subsequent users requesting legitimate resources. For instance, in a 2019 vulnerability affecting PayPal's login page, smuggled requests poisoned cached JavaScript files, enabling persistent delivery of malicious scripts across sessions. Similarly, a 2025 incident involving Cloudflare's infrastructure exposed over 24 million websites to cache poisoning, where attackers could redirect traffic to malicious domains via smuggled responses, potentially compromising user data on affected third-party sites like banking portals.[4][5][31] Another critical consequence is the injection of cross-site scripting (XSS) or cross-site request forgery (CSRF) payloads directly into victims' browsers through smuggled requests that hijack legitimate responses. This allows attackers to execute arbitrary scripts or forge actions on behalf of users without their knowledge. An example involves smuggling via Akamai's CDN on LastPass's authentication domain (auth.lastpass.com), enabling the insertion of XSS payloads like<script>alert(1)</script>, potentially stealing session tokens or credentials from unsuspecting users. In web cache poisoning scenarios, such injections have led to persistent XSS on high-traffic sites, such as an online newspaper where query reflection delivered malicious JavaScript to every cached page, risking widespread data exfiltration.[5][32]
Account takeover represents a high-impact outcome, where desynchronized requests enable attackers to hijack user sessions or steal authentication details by redirecting or intercepting sensitive operations. Through poisoned caches or response injection, attackers can manipulate login flows to capture credentials; a notable case involved PayPal in 2019, where smuggled JavaScript on Safari and Internet Explorer sub-pages bypassed content security policies, allowing password theft and earning bug bounties of $18,900 and $20,000. Another instance targeted GitLab's security reporting endpoint, where smuggling exposed vulnerability reports and enabled potential session hijacking, resulting in a $7,000 bounty.[4][33][34][5]
Finally, smuggling can cause denial-of-service (DoS) effects by queuing invalid or malformed requests that exhaust server resources or corrupt ongoing connections. Attackers may inject requests that lead to deadlocks or error states, disrupting service availability; for example, a vulnerability in T-Mobile's staging environment used an "Expect" header in smuggled requests to induce upstream deadlocks, denying access to the domain and yielding a $12,000 bounty. Historically, early smuggling attacks documented in 2005 by Watchfire demonstrated DoS through request hijacking and cache poisoning, such as manipulating connections in Microsoft ISA Server and Tomcat to cause site-wide unavailability or deadlocks, as detailed in the CERT advisory VU#625878, which highlighted risks including service disruption across affected HTTP proxies and caches. In 2025, HTTP desync attacks across various vendors resulted in over $350,000 in bug bounties, underscoring the persistent threat.[5][3][35][5]
Prevention Strategies
Configuration and Normalization Techniques
To mitigate HTTP request smuggling, server and proxy configurations should prioritize rejecting requests that introduce parsing ambiguities, particularly those containing both Content-Length (CL) and Transfer-Encoding (TE) headers, as these can lead to divergent interpretations between front-end and back-end components.[1][36] Front-end proxies can be configured to drop such ambiguous requests outright, while back-end servers should close the TCP connection upon detecting them, preventing the exploitation of persistent connections.[1][2] Header normalization techniques further reduce risks by enforcing a consistent method for delineating request bodies across the HTTP chain. For instance, configurations can mandate the use of only the Content-Length header for body length specification, rejecting or stripping the Transfer-Encoding header if present, or vice versa depending on the environment's requirements.[1][2] This normalization ensures uniform parsing, eliminating opportunities for smuggling by aligning all intermediaries to a single interpretation of body boundaries as per RFC 7230.[36] Implementing strict timeouts and buffering controls helps counter abuse of persistent connections, a common vector in smuggling attacks. Servers should apply read timeouts to limit the time allowed for receiving request data, discarding incomplete or suspicious inputs and closing connections to avoid buffering overflows or delayed smuggling payloads.[1][2] Buffering should be minimized or strictly bounded, with policies to flush or reject requests exceeding defined limits, thereby disrupting attempts to inject hidden requests over keep-alive sessions.[36] For specific tools, Apache HTTP Server can utilize theHttpProtocolOptions Strict directive to enforce rigorous compliance with HTTP/1.1 standards, rejecting non-conformant headers and requests that could enable smuggling.[37] In Nginx, configurations should include directives like proxy_set_header Transfer-Encoding ""; within proxy blocks to strip ambiguous TE headers before forwarding, combined with updating to the latest version to address known parsing inconsistencies.[1][36] These settings, when applied consistently, align front-end and back-end behaviors without relying on higher-level protocol shifts.