SwiftNIO HTTP/2: HTTP/2-to-HTTP/1 Request Smuggling via unvalidated :path pseudo-header in HTTP2ToHTTP1Codec

swift-nio-http2's HTTP/2-to-HTTP/1.1 codec (HTTP2FramePayloadToHTTP1ServerCodec / HTTP2ToHTTP1ServerCodec) did not validate pseudo-header values for control characters before placing them into the translated HTTP/1.1 message. A remote attacker could send an HTTP/2 request containing CR (\r), LF (\n), or NUL (\0) bytes in pseudo-header values such as :path, and when the server translated this to HTTP/1.1 — for example in a reverse-proxy configuration — the resulting output could contain injected headers or entirely smuggled requests.

This is an HTTP/2-to-HTTP/1.1 request smuggling vulnerability. HTTP/2's binary framing means that CRLF bytes are never parsed as line terminators at the HTTP/2 layer, so they pass through transparently to the HTTP/1.1 output. Any swift-nio-http2 server that translates HTTP/2 requests to HTTP/1.1 and forwards them to a backend is affected. Server-side Swift frameworks such as Vapor that use this codec in a reverse-proxy pattern are directly affected.

This vulnerability is related to https://github.com/advisories/GHSA-7fj7-39wj-c64f in swift-nio, which addressed CRLF injection in HTTP/1.1 header values but did not cover pseudo-header values in the HTTP/2 layer.

This vulnerability is also related to https://github.com/advisories/GHSA-cq87-8r7h-962v in swift-nio, which addressed CRLF injection in HTTP/1.1 version, method and path.

swift-nio-http2 1.44.0 adds validation of all pseudo-header values (:path, :authority, :scheme, :method, and :status) at both the HPACK header validation layer and the HTTP/2-to-HTTP/1.1 translation layer. Requests or responses containing CR, LF, or NUL bytes in any pseudo-header value are now rejected with a connection error.

SwiftNIO recommends all adopters upgrade to 1.44.0 as soon as possible.

SwiftNIO thanks @kuranikaran for filing this issue and the support in fixing it.