HTTP Request Smuggling: TE.TE desync and obs-fold parsing in WEBrick

[rodtvs]

Summary

WEBrick contains two independent weaknesses in HTTP/1.1 request parsing
that create HTTP Request Smuggling conditions when deployed behind a
reverse proxy (Nginx, HAProxy, AWS ALB) with connection pooling.

Both bugs are confirmed directly in WEBrick via raw TCP no proxy
required to reproduce the parsing behavior.

This report was originally submitted via HackerOne with PoC and redirected here by @hsbt.

---

Bug 1 TE.TE Desync: Multiple Transfer-Encoding Headers

File: lib/webrick/httputils.rb:155-159 / lib/webrick/httprequest.rb:550-557
CWE: CWE-444

When a request contains multiple Transfer-Encoding headers, WEBrick
joins their values using ", " via SplitHeader#join, producing
"chunked, identity". This fails the regex /\Achunked\z/io, causing
WEBrick to return 501 Not Implemented instead of the RFC-required
400 Bad Request.

The unread body bytes remain in the socket buffer and are processed
as the next request under a keep-alive connection.

Minimal reproduction (direct TCP, no proxy):

import socket

def raw(payload):
    s = socket.socket()
    s.connect(("127.0.0.1", 18080))
    s.sendall(payload)
    r = b""
    s.settimeout(2)
    try:
        while True:
            c = s.recv(4096)
            if not c: break
            r += c
    except: pass
    s.close()
    return r.decode(errors="replace")

# Single TE header -> 200 OK
raw(b"POST /submit HTTP/1.1\r\nHost: localhost\r\n"
    b"Transfer-Encoding: chunked\r\nConnection: close\r\n\r\n"
    b"5\r\nhello\r\n0\r\n\r\n")

# Two TE headers -> 501 Not Implemented
raw(b"POST /submit HTTP/1.1\r\nHost: localhost\r\n"
    b"Transfer-Encoding: chunked\r\n"
    b"Transfer-Encoding: identity\r\n"
    b"Connection: close\r\n\r\n"
    b"5\r\nhello\r\n0\r\n\r\n")

Observed output (WEBrick 1.9.2 / Ruby 4.0.1):

Single TE:  HTTP/1.1 200 OK
Two TE:     HTTP/1.1 501 Not Implemented
            body: "Transfer-Encoding: chunked, identity."

The 501 response body exposes the joined value, confirming
SplitHeader#join in httputils.rb:156 as the root cause.

---

Bug 2 - Obs-fold Desync: Obsolete Line Folding in Transfer-Encoding

File: lib/webrick/httputils.rb:181-188
CWE: CWE-444

WEBrick's parse_header merges obs-fold continuation lines into the
previous header value. A request containing:

Transfer-Encoding: chunked\r\n
\tidentity\r\n

Is parsed by WEBrick as Transfer-Encoding: chunked identity.

Frontend proxies that do not support obs-fold (HAProxy < 2.0.6, standard
Nginx) see only Transfer-Encoding: chunked and process the body
accordingly - creating a parsing asymmetry that is the foundation of
TE.TE smuggling. This is the same mechanism documented in CVE-2019-18277.

RFC 7230 §3.2.6 states servers MUST either reject obs-fold in request
headers or replace it with SP octets. WEBrick applies the second option
but does not validate the resulting TE value, leaving the desync surface open.

---

Affected Versions

Confirmed on WEBrick 1.9.2 / Ruby 4.0.1. Likely affects earlier versions.

---

Recommended Fixes

Bug 1 - Reject multiple Transfer-Encoding headers

# lib/webrick/httprequest.rb - inside read_header
if (te = @header['transfer-encoding']) && te.length > 1
  raise HTTPStatus::BadRequest, "multiple transfer-encoding headers"
end

Bug 2 - Reject obs-fold in request headers

# lib/webrick/httputils.rb:181-188
when /^[ \t]+([^\r\n\0]*?)\r\n/om
  raise HTTPStatus::BadRequest,
    "obs-fold in request header is not allowed (RFC 7230 §3.2.6)"

---

References

• RFC 7230 §3.3.1 - Transfer-Encoding header field
• RFC 7230 §3.2.6 - Obs-fold deprecation
• CVE-2020-25613 - Prior WEBrick HTTP Request Smuggling
• CVE-2019-18277 - HAProxy obs-fold smuggling
• https://nathandavison.com/blog/haproxy-http-request-smuggling
• PortSwigger: https://portswigger.net/web-security/request-smuggling

Full technical details and end-to-end PoC available upon request.

[jeremyevans]

Thank you for the report. I submitted #205 to fix this. Can you please check and let me know whether that fixes the issue for you?

[rhenium]

When a request contains multiple Transfer-Encoding headers, WEBrick joins their values using ", " via SplitHeader#join, producing "chunked, identity". This fails the regex /\Achunked\z/io, causing WEBrick to return 501 Not Implemented instead of the RFC-required 400 Bad Request.

Could you point me to the relevant part of the RFCs? From a quick look at RFC9110 and RFC9112, a 501 return seems to be a correct behavior, if WEBrick doesn't understand the "chunked, identity" transfer encoding.

The Transfer-Encoding header field is specified to be a comma-separated list and I couldn't find a requirement to treat this header differently from others.

https://datatracker.ietf.org/doc/html/rfc9110#section-5.3
https://datatracker.ietf.org/doc/html/rfc9112#section-6.1

The unread body bytes remain in the socket buffer and are processed
as the next request under a keep-alive connection.

Doesn't WEBrick::HTTPRequest#fixup handle this already?

[rhenium]

RFC 7230 §3.2.6 states servers MUST either reject obs-fold in request
headers or replace it with SP octets. WEBrick applies the second option
but does not validate the resulting TE value, leaving the desync surface open.

As you saw in the first item, WEBrick does validate the value when trying to read the request body, which results in HTTPStatus::NotImplemented being raised because a transfer encoding "chunked identity" is not recognized.

It seems the handling of line folding was changed between RFC 2616 and RFC 7320:
https://datatracker.ietf.org/doc/html/rfc2616#section-2.2
https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.4

While I think WEBrick could start to reject the request as soon as it encounters a line folding according to the new RFCs, the current behavior doesn't seem to me to enable request smuggling.

[jeremyevans]

My feeling here is no legitimate request will be sending multiple transfer-encoding headers, so rejecting requests that include them seems fine as it would only reject malicious requests. However, I don't have strong feelings on the matter.

[rhenium]

Yes, and WEBrick appears to reject such requests in one of the acceptable ways already.

[rodtvs]

First thanks @rhenium and @jeremyevans ❤️

After empirically testing the attack vectors, I want to correct and clarify several
claims in my original report.

---

On byte injection (the core smuggling mechanism)

I tested all variants against WEBrick directly (no proxy), using a single persistent
TCP connection that sent the malicious request immediately followed by a smuggled
request simulating the worst-case pipelining scenario:

1. Double TE headers + pipelined smuggled request -> 1 response (501), connection closed
2. Obs-fold TE + pipelined smuggled request -> 1 response (501), connection closed
3. Send-before-response pipelining -> 1 response (501), connection closed

The connection closure prevents byte injection.

The claim in my report "unread body bytes remain in the socket buffer" was
technically accurate but incomplete: those bytes are discarded when the connection
closes, so there is no next-request contamination. The direct buffer-poisoning attack does not work against WEBrick.

---

On the fixup mechanism

A clarification on the exact code path: fixup is not actually invoked for
5xx error responses.

HTTPResponse#set_error sets @keep_alive = false for any HTTPStatus::error?
code (httpresponse.rb:408), so the guard at httpserver.rb:114
(req.keep_alive? && res.keep_alive?) evaluates to false before fixup is
reached. The bytes are discarded via connection closure
(break unless res.keep_alive? at line 123), not via fixup draining them, or maybe i'm wrong.

Same net result, different mechanism but the distinction matters for understanding
the actual code path.

---

On 501 vs 400

You are right, @rhenium. RFC 9112 §6.1 allows 501 for unrecognized transfer codings. My report cited RFC 7230, which has been obsoleted by RFC 9112. I concede that point.

---

On the end-to-end PoC

Looking at the original PoC more carefully: the end-to-end smuggling demonstration uses Content-Length undersizing (CL:10 with a larger body), not the TE.TE bug. That attack works because the Python proxy in the PoC forwards all received bytes to the backend without enforcing Content-Length. A standards-compliant proxy like Nginx does not behave this way unless other custom proxies, this was a misattribution on my part.

---

Deeper empirical analysis additional vectors tested

Before concluding, I extended the testing to cover all plausible obfuscation variants
to ensure no other vector was overlooked.

Vectors that WEBrick already handles correctly (error + close, no byte injection)

Payload	WEBrick response	Notes
TE: chunked + TE: identity (RS-001)	501 + close	Confirmed: no injection
TE: chunked\r\n\tidentity obs-fold (RS-002)	501 + close	Confirmed: no injection
TE: chunked;ext=foo (chunk extension)	501 + close	regex /\Achunked\z/ rejects extension
TE: identity,chunked (list, chunked last)	501 + close	composite value rejected
Content-Length: 0 + Content-Length: 100	400 + close	explicit check at httprequest.rb:501-502
Content-Length: 100 + Transfer-Encoding: chunked	400 + close	explicit check at httprequest.rb:551-552

WEBrick already has explicit protections for duplicate Content-Length headers
(content_length.length > 1 -> BadRequest) and for the CL+TE combination. These are correctly handled.

The one confirmed end-to-end smuggling path

There is a real end-to-end attack, but the vulnerable component is the proxy, not WEBrick. The attack requires a proxy that:

1. Strips obs-fold continuation lines from TE headers (forwarding only TE: chunked)
2. Forwards body bytes verbatim to the backend - including bytes past the chunk terminator (this is the proxy bug)

When these conditions are met, WEBrick correctly reads the zero-length chunk, marks
the body as done, and keeps the connection alive. The smuggled bytes that follow the 0\r\n\r\n terminator remain in the socket buffer and are read as the next request (smuggle will work).

Empirically confirmed (direct connection to WEBrick):

Request to WEBrick:
  POST /submit HTTP/1.1
  Transfer-Encoding: chunked
  [blank line]
  0\r\n\r\n
  GET /admin/users HTTP/1.1\r\n...

Responses received: 2
  Resp #1: HTTP/1.1 200 OK  {"status":"ok","received":0}
  Resp #2: HTTP/1.1 200 OK  {"users":[{"id":1,"username":"alice",...}]}

Control test ( AB test ) - does the obs-fold trigger this, or does a plain chunked request also produce the same result?

With obs-fold TE  -> smuggling: YES
Without obs-fold  -> smuggling: YES (identical)

Conclusion: the obs-fold is not the enabling condition for this attack. Any request with chunked body and extra bytes after the terminator produces the same result. The attack depends entirely on a proxy that does not properly bound the
forwarded body to the decoded chunk content. This is a proxy-side vulnerability. WEBrick behaves correctly per RFC: it processes the chunked body and continues on the keep-alive loop. Any compliant HTTP/1.1 server would behave the same way.

---

Revised position

Claim in original report	Revised assessment
501 instead of 400 is non-compliant	Withdrawn - 501 is RFC 9112-acceptable
Byte injection via TE.TE causes buffer poisoning	Withdrawn - connection close discards bytes
Obs-fold enables smuggling	Partially withdrawn - RS-002 creates parsing asymmetry, but is not the enabling condition for byte injection
End-to-end PoC demonstrates WEBrick smuggling	Withdrawn PoC uses CL undersize attack against a non-compliant proxy
Parsing asymmetry is a real structural condition	Maintained

The parsing asymmetry produced by SplitHeader#join and obs-fold merging is still a real concern: it means WEBrick and a frontend proxy can parse the same raw bytes into semantically different requests. Even if there is no direct exploit path today
with standards-compliant proxies, this is the structural precondition for TE.TE-class smuggling and warrants remediation.

---

On PR #205

The fix rejecting duplicate TE headers and obs-fold in TE with 400 at parse_header time is the correct approach. It eliminates the parsing asymmetry at the source, at the earliest possible point, and returns the semantically appropriate response code for a malformed request (400 Bad Request= "I understood your request but it is malformed") rather than the current 501 (which implies the encoding is merely unsupported).

I confirm it addresses both issues in the original report and support merging it.

Revised severity: Low to Medium the bugs are real parser non-conformances that create a structural smuggling surface.

Thanks again @rhenium and @jeremyevans. I learned a lot by reading the code you guys wrote, thank you so much!