HSEC-2026-0013

Dashboard / Vulnerabilities / HSEC-2026-0013

HSEC-2026-0013

Summary: HTTP Request Smuggling in warp

Details: # 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.

References: https://github.com/yesodweb/wai/issues/1129, https://github.com/yesodweb/wai/compare/warp-3.4.16...warp-3.4.17, https://hackage.haskell.org/package/warp