# Security release: SwiftNIO 2.100.0, SwiftNIO HTTP/2 1.44.0, SwiftNIO Extras 1.34.1

**URL:** <https://forums.swift.org/t/security-release-swiftnio-2-100-0-swiftnio-http-2-1-44-0-swiftnio-extras-1-34-1/86873>\
**Category:** Security Updates\
**Tags:** security\
**Created:** [May 21, 2026, 6:31pm UTC](https://forums.swift.org/t/security-release-swiftnio-2-100-0-swiftnio-http-2-1-44-0-swiftnio-extras-1-34-1/86873 "2026-05-21T18:31:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![fabianfett](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/fabianfett/32/10042_2.png) [@fabianfett](https://forums.swift.org/u/fabianfett)\
**Post date:** [May 21, 2026, 6:31pm UTC](https://forums.swift.org/t/security-release-swiftnio-2-100-0-swiftnio-http-2-1-44-0-swiftnio-extras-1-34-1/86873/1 "2026-05-21T18:31:17Z")

</div>

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](https://github.com/apple/swift-nio/security/advisories/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](https://github.com/apple/swift-nio/security/advisories/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](https://github.com/apple/swift-nio/security/advisories/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](https://github.com/apple/swift-nio-http2/security/advisories/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](https://github.com/apple/swift-nio-extras/security/advisories/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](https://github.com/advisories/GHSA-xhhr-p2r9-jmm7)**  **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