Hi everyone,
We have released security fixes today across the SwiftNIO family. We recommend that all users upgrade as soon as possible.
| Package | Fixed version |
|---|---|
swift-nio |
2.100.0 |
swift-nio-http2 |
1.44.0 |
swift-nio-extras |
1.34.1 |
Five advisories are addressed across these releases. Brief summaries below; please refer to each advisory for full detail.
swift-nio 2.100.0
GHSA-r3rc-9hpw-54v9 — Out-of-bounds write via ByteBuffer index/length overflow (high severity, CVE-2026-43671)
ByteBuffer 's internal _toIndex / _toCapacity helpers used UInt32(truncatingIfNeeded:) , silently truncating index or length values larger than UInt32.max on 64-bit platforms. The most impactful affected methods are copyBytes(at:to:length:) and writeWithUnsafeMutableBytes(minimumWritableBytes:) ; in release builds, a crafted >4 GiB index could lead to out-of-bounds heap writes. In practice, exploitation requires an application to forward attacker-influenced values exceeding 4 GiB into one of these write paths, which is unusual — most applications are not exploitable for memory corruption, though some may experience logical/buffer-corruption issues. Other affected methods (moveReaderIndex /moveWriterIndex(forwardBy:) , ByteBuffer(takingOwnershipOf:allocator:) ) only produce logical errors, not memory-safety issues.
GHSA-rj37-6j9x-74q6— Unbounded HTTP/1 header blocks enable remote DoS (medium severity, CVE-2026-28980)
HTTPDecoder previously enforced only an 80 KB per-field limit, with no cap on total header block size or header count. A single unauthenticated request with hundreds of thousands of small headers could exhaust server memory, and on stacks that bridge HTTPHeaders into swift-http-types ' HTTPFields (e.g. Hummingbird 2) could crash the process via a HTTPFields precondition. 2.100.0 introduces NIOHTTPDecoderLimitConfiguration with conservative defaults: 80 KB per field, 2 MB total header list, 256 fields per message. Applications with legitimate need for larger limits can opt in explicitly. Thanks to @Joannis for the report.
GHSA-cq87-8r7h-962v — CRLF injection in outbound HTTP request URI / method / response reason phrase (medium severity, CVE-2026-28970)
NIOHTTPRequestHeadersValidator / NIOHTTPResponseHeadersValidator validated header names and values, but not the request URI, request method, or response reason phrase. Applications that emit attacker-influenced data in those start-line fields (e.g. proxies forwarding URIs) were vulnerable to HTTP request smuggling and response splitting. 2.100.0 extends both validators to enforce the URI/method/reason-phrase grammars from RFC 9110 / 9112 / 3986, rejecting invalid outbound messages with HTTPParserError.invalidHeaderToken . Thanks to @kuranikaran and @YLChen-007 for the reports.
swift-nio-http2 1.44.0
GHSA-4px2-pw77-vc85 — HTTP/2 → HTTP/1 request smuggling via unvalidated :path pseudo-header (low severity, CVE-2026-28898)
The 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. Because HTTP/2 framing carries CR/LF transparently, a remote attacker could smuggle requests by injecting CR, LF, or NUL bytes into :path , :authority , etc. — a particular concern for reverse-proxy deployments (e.g. Vapor). 1.44.0 adds validation of all pseudo-header values at both the HPACK and HTTP/2-to-HTTP/1.1 translation layers. This complements the swift-nio fixes above. Thanks to @kuranikaran for the report.
swift-nio-extras 1.34.1
GHSA-6ph5-fww6-vfwv — NIOHTTPRequestDecompressor ratio-limit bypass via inflated Content-Length (medium severity, CVE-2026-28975)
When NIOHTTPRequestDecompressor is configured with .ratio(N) , the limit was checked against the attacker-supplied Content-Length header rather than the actual compressed bytes received. By setting Content-Length to match the decompressed size, a client could disable the ratio check entirely and submit a small, highly-compressed "gzip bomb" that decompresses without bound. *Users who adopted .ratio(N) as the recommended workaround for CVE-2020-9840 are affected. The fix accumulates actual compressed bytes received. Thanks to @nathanielmiller23 for the report.
If you depend on any of these libraries — directly or transitively — please bump your version constraints and rebuild as soon as possible.
— The SwiftNIO team