The HTTP/1 client serialized request.method and request.target (and, in forward-proxy absolute-form, the host) verbatim onto the wire with no CR/LF/CTL filtering; the only target validator was wired solely into the server parse path. A caller passing an attacker-influenced URL or method to the client could embed \r\n in the method, path, or query to inject arbitrary request headers, or \r\n\r\n to smuggle a second pipelined request onto a pooled keep-alive (or proxy-forwarded) connection. The HTTP/2 client already rejected CR/LF in :path, so this was an HTTP/1-specific omission.
CR/LF injection in client request start lines could lead to header injection and request smuggling on reused or proxied connections.
Fixed in HTTP.jl v2.4.0. A new _validate_request_start_line! validates the method against the RFC 7230 token grammar, delegates target validation to the existing _validate_request_target!, and rejects control bytes in a supplied host. It is wired into all HTTP/1 wire start-line writers (origin-form, CONNECT authority-form, asterisk-form, websocket, and forward-proxy absolute-form) before any bytes are emitted, rejecting offending requests with a ParseError.
Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.
{
"license": "CC-BY-4.0"
}