HSEC-2026-0013
Vulnerability from osv_haskell – Published: 2026-11-04 12:43 – Updated: 2026-11-04 12:43 – Source websiteHTTP 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-EncodingandContent-Lengthfield lines were collapsed to a single value, the last line winning. A secondContent-Lengthcould hide the first, and a secondTransfer-Encodingcould hide achunkedcoding.- Sending
Content-Lengthtogether withTransfer-Encoding, or aTransfer-Encodingwhose final coding is notchunked, was not refused; warp resolved the ambiguity by reading whichever framing it recognised. Content-Lengthvalues were parsed by reading the leading digits: a non-numeric value, or one too large for anIntwhich 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.
{
"affected": [
{
"database_specific": {
"human_link": "https://github.com/haskell/security-advisories/tree/main/advisories/published/2026/HSEC-2026-0013.md",
"osv": "https://raw.githubusercontent.com/haskell/security-advisories/refs/heads/generated/osv-export/2026/HSEC-2026-0013.json"
},
"package": {
"ecosystem": "Hackage",
"name": "warp"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.3"
},
{
"fixed": "3.4.17"
}
],
"type": "ECOSYSTEM"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
],
"database_specific": {
"home": "https://github.com/haskell/security-advisories",
"osvs": "https://raw.githubusercontent.com/haskell/security-advisories/refs/heads/generated/osv-export",
"repository": "https://github.com/haskell/security-advisories"
},
"details": "# HTTP Request Smuggling in warp\n\nwarp\u0027s 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\u0027s HTTP/2 support delegates parsing to the `http2` package and is not affected.\n\nSix defects were fixed in warp 3.4.17:\n\n* `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.\n* 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.\n* `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 \u2014 so the request body was read as the next request on the connection.\n* 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`.\n* 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.\n* 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.\n\nExploitation of the framing defects requires a front-end \u2014 reverse proxy, load balancer, WAF \u2014 that parses the ambiguous request differently from warp; the truncated-chunk defect also affects directly exposed servers.\n\n## Resolution\n\nwarp 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.\n\nUsers 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\u0027s tags; older release series are unsupported and should be upgraded regardless.\n",
"id": "HSEC-2026-0013",
"modified": "2026-11-04T12:43:59Z",
"published": "2026-11-04T12:43:59Z",
"references": [
{
"type": "REPORT",
"url": "https://github.com/yesodweb/wai/issues/1129"
},
{
"type": "FIX",
"url": "https://github.com/yesodweb/wai/compare/warp-3.4.16...warp-3.4.17"
},
{
"type": "PACKAGE",
"url": "https://hackage.haskell.org/package/warp"
}
],
"schema_version": "1.5.0",
"summary": "HTTP Request Smuggling in warp"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.