swift-nio-http2 EUVD-2026-39533

Two concrete conditions must both be met: first, the server must run swift-nio-http2 at a version earlier than 1.44.1 with either HTTP2FramePayloadToHTTP1ServerCodec or HTTP2ToHTTP1ServerCodec active in the request pipeline; second, the server must operate in a reverse-proxy or protocol-bridging mode where HTTP/2 requests are translated to HTTP/1.1 and forwarded to a backend - this is the explicit deployment pattern identified in the advisory. No authentication is required (PR:N per independent CVSS assessment); the attacking client only needs the ability to reach the HTTP/2 listener and send a request containing control characters in a pseudo-header value. Exploitation is limited by the following: a swift-nio-http2 server that terminates HTTP/2 as a final endpoint without any HTTP/1.1 backend forwarding is not exploitable; the attack requires the HPACK layer to pass the malformed pseudo-header without prior rejection (pre-1.44.1 behavior does not validate these values); and backend exploitation impact depends on whether the backend HTTP/1.1 server shares connection state across requests.

The CVSS vector supplied in the source data (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N) is a placeholder with zero impact scores and must not be used for prioritization decisions - it does not reflect any real severity assessment of this vulnerability. An independent assessment assigns high integrity impact with scope change because successful exploitation allows injected requests to reach a backend system outside the proxy's trust boundary. Real-world risk is strongly topology-dependent: deployments where swift-nio-http2 terminates HTTP/2 as a final endpoint without backend forwarding are not exploitable, while any reverse-proxy or API gateway pattern translating HTTP/2 to HTTP/1.1 backends is directly exposed. EPSS data is absent from available intelligence, so statistical exploitation probability cannot be quantified. The vulnerability is not in CISA KEV and no POC code is referenced in the advisory. However, the technique is well-documented in the HTTP request smuggling literature, the affected library family has had two prior CRLF injection fixes, and no authentication is required - these factors combine to make exploitation plausible by a motivated attacker in a targeted engagement against a known deployment. The Vapor framework is explicitly named as a directly affected consumer.

An attacker sends an HTTP/2 request to a swift-nio-http2 reverse-proxy with a crafted :path value such as /api/data X-Forwarded-For: 127.0.0.1

POST /admin HTTP/1.1 Host: backend - which is syntactically valid in HTTP/2's binary framing layer and passes through without error. When the codec translates this to HTTP/1.1 and forwards it to the backend, the embedded CRLF bytes become structural delimiters, causing the backend parser to interpret the payload as containing an injected header and a second smuggled POST request to the /admin endpoint. This could allow the attacker to bypass proxy-enforced authentication headers, poison shared backend connection state, or reach restricted backend endpoints not intended to be exposed via the proxy.