HSEC-2026-0013: HTTP Request Smuggling in warp

HTTP Request Smuggling in warp

warp's HTTP/1.x request parser accepted request framing that RFC 9112 requires recipients to refuse, so a request could frame one way for a front-end proxy reading it and another way for warp behind it. Whoever reads such a request the other way sees one request where the other sees two, which smuggles a request past the proxy: past access control, request validation, logging, or WAF rules. warp's HTTP/2 support delegates parsing to the http2 package and is not affected.

Six defects were fixed in warp 3.4.17:

Transfer-Encoding and Content-Length field lines were collapsed to a single value, the last line winning. A second Content-Length could hide the first, and a second Transfer-Encoding could hide a chunked coding. Sending Content-Length together with Transfer-Encoding, or a Transfer-Encoding whose final coding is not chunked, was not refused; warp resolved the ambiguity by reading whichever framing it recognised. Content-Length values were parsed by reading the leading digits: a non-numeric value, or one too large for an Int which then wrapped, became length 0 — so the request body was read as the next request on the connection. Header field names were not validated: an obs-fold continuation line, a name containing whitespace or control characters, or an empty name became a header warp did not act on but a repairing intermediary could, including a hidden Content-Length. A bare CR or a NUL inside a header field line was accepted; an intermediary that takes a bare CR for a line terminator reads a field line where warp reads none. The chunked body parser did not keep to RFC 9112: a chunk size was the fold of whatever hex digits a line led with, a chunk not closed off by CRLF ended the body early, a size line split over several reads was mis-read, and the trailer section was left in the connection to be parsed as the next request. A chunked body cut short by the end of input was handed to the application as though it were whole (yesodweb/wai#1129), so an upload could be stored truncated and answered 200.

Exploitation of the framing defects requires a front-end — reverse proxy, load balancer, WAF — that parses the ambiguous request differently from warp; the truncated-chunk defect also affects directly exposed servers.

Resolution

warp 3.4.17 validates the framing and refuses requests it cannot frame reliably, raising InvalidRequest with the new constructors UnsupportedTransferEncoding, AmbiguousBodyLength, BadFieldName, BadHeaderLine and BadChunkedBody; the default exception response is 400, or 501 for a transfer coding warp cannot decode.

Users are advised to upgrade to warp 3.4.17 or later. The lax parsing is verified back to warp 1.3.3, the oldest source retained in the upstream repository's tags; older release series are unsupported and should be upgraded regardless.