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

Vulnerability

The HTTP2FramePayloadToHTTP1ServerCodec and HTTP2ToHTTP1ServerCodec in swift-nio-http2 prior to version 1.44.0 did not validate pseudo-header values for control characters (CR, LF, NUL) before translating them into HTTP/1.1 messages. A remote attacker can send an HTTP/2 request containing these bytes in pseudo-headers such as :path, :authority, :scheme, :method, or :status. Because HTTP/2 uses binary framing, these bytes are not interpreted as line terminators at the HTTP/2 layer and are passed transparently to the HTTP/1.1 output. Any server using swift-nio-http2 in a reverse-proxy configuration that translates HTTP/2 to HTTP/1.1 is affected, including frameworks like Vapor[1][2].

Exploitation

An attacker can craft an HTTP/2 request with a pseudo-header value containing CR, LF, or NUL bytes – for example, embedding \r\n in the :path pseudo-header. No prior authentication or special privileges are required. The attacker only needs to be able to send HTTP/2 requests to the vulnerable server. When the server translates this request to HTTP/1.1 and forwards it to a backend, the injected control characters can break the HTTP/1.1 request line or header parsing, potentially allowing the attacker to inject additional headers or entire smuggled requests[1][2].

Impact

Successful exploitation results in HTTP/2-to-HTTP/1.1 request smuggling. An attacker can inject arbitrary HTTP headers or entire requests into the backend connection, potentially leading to cache poisoning, request routing attacks, or bypassing security controls. The exact impact depends on the backend server and application logic[1][2].

Mitigation

The vulnerability is fixed in swift-nio-http2 version 1.44.0, released on 2026-06-12. This version adds validation of all pseudo-header values (:path, :authority, :scheme, :method, :status) at both the HPACK header validation layer and the HTTP/2-to-HTTP/1.1 translation layer. Requests containing CR, LF, or NUL bytes in any pseudo-header are now rejected with a connection error. No workaround is available; all adopters should upgrade immediately[1][2].