{"id":"ANT-2026-CN279YCX","aliases":["ANT-2026-MG2WTZ8Z","ANT-2026-SRPX7DN1","ANT-2026-YD5QTQDZ","JLSEC-2026-618"],"status":"published","title":"HTTP/1 request smuggling via bare-LF, lenient chunk size, and TE/CL handling in HTTP.jl server","description":"### Description\n\nThe HTTP/1 server request parser had three framing primitives that could make HTTP.jl disagree with a fronting proxy about message boundaries on a reused keep-alive connection. (1) `_readline_crlf` tolerated a bare `LF` on its buffered fast path but required `CRLF` on the slow path, so the accepted header grammar depended on TCP segmentation and an absorbed bare `LF` could silently merge headers. (2) `_parse_chunk_size` delegated to `Base.parse(Int64, ...; base=16)`, which tolerates a leading sign, a `0x` prefix, and whitespace padding (including a trailing bare `CR`). (3) For HTTP/1.0, `Transfer-Encoding` was stripped with a fallback to `Content-Length` while the connection could stay open, and a request carrying both `Transfer-Encoding` and `Content-Length` was silently treated as chunked.\n\n### Impact\n\nThese parsing discrepancies enabled HTTP request smuggling past a fronting proxy on pooled/keep-alive connections.\n\n### Patches\n\nFixed in HTTP.jl v2.4.0. Both line-reading paths now require a strict `CRLF` and reject a bare `LF`; chunk sizes use a strict byte-by-byte `1*HEXDIG` parser (rejecting signs, prefixes, and whitespace); HTTP/1.0 messages carrying `Transfer-Encoding` are rejected; and any request carrying both `Transfer-Encoding` and `Content-Length` is rejected. All rejections surface as a 400 with the connection force-closed so no ambiguous trailing bytes remain.\n\nReported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.","facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2026-06-23T12:59:32.708Z","modified":"2026-07-21T14:00:03Z","fixes":[{"ecosystem":"Julia","package":"HTTP","fixed_in":["2.4.0"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Julia","package":"HTTP","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.4.0"}]}]}],"references":[{"url":"https://github.com/JuliaWeb/HTTP.jl/commit/2091b63e0a71c177625385bdb819345a69487342","tags":["web"]},{"url":"https://github.com/JuliaWeb/HTTP.jl/pull/1316","tags":["web"]}],"sources":{"osv":[{"id":"JLSEC-2026-618","title":"HTTP/1 request smuggling via bare-LF, lenient chunk size, and TE/CL handling in HTTP.jl server","description":"### Description\n\nThe HTTP/1 server request parser had three framing primitives that could make HTTP.jl disagree with a fronting proxy about message boundaries on a reused keep-alive connection. (1) `_readline_crlf` tolerated a bare `LF` on its buffered fast path but required `CRLF` on the slow path, so the accepted header grammar depended on TCP segmentation and an absorbed bare `LF` could silently merge headers. (2) `_parse_chunk_size` delegated to `Base.parse(Int64, ...; base=16)`, which tolerates a leading sign, a `0x` prefix, and whitespace padding (including a trailing bare `CR`). (3) For HTTP/1.0, `Transfer-Encoding` was stripped with a fallback to `Content-Length` while the connection could stay open, and a request carrying both `Transfer-Encoding` and `Content-Length` was silently treated as chunked.\n\n### Impact\n\nThese parsing discrepancies enabled HTTP request smuggling past a fronting proxy on pooled/keep-alive connections.\n\n### Patches\n\nFixed in HTTP.jl v2.4.0. Both line-reading paths now require a strict `CRLF` and reject a bare `LF`; chunk sizes use a strict byte-by-byte `1*HEXDIG` parser (rejecting signs, prefixes, and whitespace); HTTP/1.0 messages carrying `Transfer-Encoding` are rejected; and any request carrying both `Transfer-Encoding` and `Content-Length` is rejected. All rejections surface as a 400 with the connection force-closed so no ambiguous trailing bytes remain.\n\nReported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.","status":"published","published":"2026-06-23T12:59:32.708Z","modified":"2026-07-21T14:00:03.540753577Z","updated_at":"2026-11-02T15:47:18.573531Z"}]}}