SwiftNIO NIOHTTP1: HTTPDecoder accepts unbounded HTTP/1 header blocks, enabling remote DoS
Summary
The HTTPDecoder in NIOHTTP1 enforces no limit on the total size of an HTTP/1 message's header block or on the number of header fields per message. A remote peer can submit an arbitrary number of small, valid headers in a single request and have them all accumulated into the resulting HTTPHeaders value before any application code runs. This can be used to exhaust memory, or — for consumers that subsequently convert headers into swift-http-types' HTTPFields — to crash the process.
Details
HTTPDecoder previously enforced only a single hardcoded parsing limit: 80 KB per individual header field (name + value). There was no cap on the cumulative size of the header block, nor on the number of header fields per message. Because each individual field can remain well below the 80 KB threshold, a peer can submit hundreds of thousands of valid headers in a single request, all of which are appended to the decoded HTTPHeaders without bound.
The headers are then visible to user code through the standard HTTPServerRequestPart.head / HTTPClientResponsePart.head events. Two observed downstream effects:
Hummingbird 2 (and other consumers that bridge HTTPHeaders into swift-http-types' HTTPFields) crashes via a precondition failure inside HTTPFields once the configured field count is exceeded.
Vapor 4 does not crash, but the per-request memory footprint scales linearly with the number of headers received, allowing a single connection to inflate server memory use substantially.
Impact
A single unauthenticated remote peer can trigger a denial of service against any HTTP/1 server (or, in the response direction, any HTTP/1 client) built on NIOHTTP1 — either by crashing the process, depending on the downstream framework, or by driving the process's resident memory to arbitrary sizes.
Patches
This issue is addressed in swift-nio 2.100.0 and later.
The HTTPDecoder now applies three parsing limits with conservative defaults, exposed through the new NIOHTTPDecoderLimitConfiguration type:
| Limit | Default |
| --- | --- |
| maxHeaderFieldSize | 80 KB |
| maxHeaderListSize | 2 MB |
| maxHeaderFieldCount | 256 |
Exceeding any of these limits causes the decoder to fail with HTTPParserError.headerOverflow. The configuration can be supplied directly to HTTPRequestDecoder / HTTPResponseDecoder, or via the decoderConfiguration property on NIOUpgradableHTTPServerPipelineConfiguration and NIOUpgradableHTTPClientPipelineConfiguration.
Users who require larger limits — for example, applications that legitimately exchange very large header blocks — can opt into them explicitly by constructing a custom NIOHTTPDecoderLimitConfiguration.
Workarounds
Users unable to upgrade can mitigate by placing a reverse proxy in front of the service that enforces equivalent limits on request header count and total header size.
Credit
This issue was reported by @Joannis. SwiftNIO thanks @Joannis for the report and the support in landing the fix.
SwiftNIO: Out-of-bounds write via ByteBuffer index and length UInt32 overflow
Summary
A program using swift-nio is vulnerable to a potential out-of-bounds write when attacker-controlled index or length values exceeding UInt32.max are passed to some ByteBuffer methods. This affects all swift-nio versions from 1.0.0 to 2.99.0. It is fixed in 2.100.0 and later releases.
Details
ByteBuffer internally stores indices and capacities as UInt32 values. The internal helper functions _toIndex and _toCapacity, which convert from Int to UInt32, used UInt32(truncatingIfNeeded:). On 64-bit platforms, this silently discards the upper 32 bits of the value rather than trapping on overflow. For example, a value of UInt32.max + 1 (0x100000000) would be truncated to 0.
This truncation can cause safety preconditions to pass when they should fail. Subsequent operations would then use the incorrect truncated value, potentially leading to out-of-bounds memory writes or reads.
The affected ByteBuffer methods that may lead to out-of-bounds writes are:
copyBytes(at:to:length:) — a crafted destination index exceeding UInt32.max could copy bytes to an incorrect offset.
writeWithUnsafeMutableBytes(minimumWritableBytes:) — a crafted minimumWritableBytes exceeding UInt32.max could provide the caller with a buffer pointer of incorrect length, which can easily be subsequently overflowed.
The affected ByteBuffer methods that have logic errors but do neither expose out-of-bounds reads nor out-of-bounds writes:
moveReaderIndex(forwardBy:) / moveWriterIndex(forwardBy:) — a crafted offset exceeding UInt32.max could move indices to incorrect positions, bypassing bounds checks. These indices cannot be out of the bounds of the buffer, so they do not expose access to uninitialized memory or produce wild pointers.
The ByteBuffer(takingOwnershipOf:allocator:) initialiser — passing a buffer larger than UInt32.max bytes could create a ByteBuffer with an incorrect capacity.
Outside of these methods, there are still impacts, but they are simply logical bugs. In these cases applications can be forced to read from or write to unexpected parts of the buffer. This does not cause memory-safety issues, but it can cause logical issues or corruption of outbound packets.
Impact
Exploitation requires an attacker to influence the index, offset, or length parameter of the affected ByteBuffer methods with a value exceeding UInt32.max (approximately 4 GiB). This is a high bar for most applications: attacker-controlled length parameters to ByteBuffer are typically used on the read path, and the above methods are typically not used on the read paths. However, applications that calculate buffer positions arithmetically from untrusted input when attempting to do writes, or that process very large payloads, may be at risk of memory safety issues.
Other applications may encounter logical issues due to reading unexpected bytes, or writing to unexpected parts of the buffer.
When the memory-safety issue is exploitable, the consequences are severe. Because truncatingIfNeeded silently produces an incorrect but valid UInt32 value, subsequent operations may write to or read from memory outside the valid buffer region. In optimised (release) builds where preconditions are not checked, this could lead to out-of-bounds memory writes, potentially corrupting adjacent heap memory.
In debug builds, some of these conditions are caught by assertions, but truncatingIfNeeded occurs before the assertion checks the (already-truncated) value, so even assertions may not reliably catch the issue.
Patches
The issue is fixed by replacing UInt32(truncatingIfNeeded:) with UInt32(_:) in the _toIndex and _toCapacity helper functions. The UInt32(_:) initialiser traps on overflow in both debug and release builds, converting a potential silent memory corruption into a deterministic crash.
One call site in getSlice(at:length:) retains truncatingIfNeeded because prior bounds checks against the non-truncated Int values mathematically guarantee the values fit within UInt32.
Workarounds
Applications can mitigate this issue by validating that all index and length values passed to ByteBuffer methods do not exceed UInt32.max (4,294,967,295). In practice, most applications are not affected because buffer indices are derived from protocol parsing rather than raw untrusted input.
SwiftNIO: CRLF Injection in outbound HTTP request URI via NIOHTTPRequestHeadersValidator
Programs using swift-nio is vulnerable to HTTP request smuggling and HTTP response splitting attacks, caused by insufficient validation of outbound HTTP/1.1 request and response start line components.
This vulnerability affects all swift-nio versions from 2.0.0 to 2.99.0. It is fixed in 2.100.0 and later releases.
This vulnerability is caused by the NIOHTTPRequestHeadersValidator and NIOHTTPResponseHeadersValidator channel handlers only validating header field names and values, while leaving the request URI, request method, and response reason phrase unvalidated. An attacker who can influence the content of these fields — for example by controlling a URL path or a custom HTTP method in a proxy application — can inject CR/LF sequences or other control characters into the HTTP start line. This allows construction of arbitrary additional HTTP requests or responses on the wire, a classic HTTP request smuggling or HTTP response splitting attack.
Exploiting this vulnerability requires the attacker to influence the content of outbound HTTP start line fields. In proxy applications that forward attacker-controlled URIs or methods, this is straightforward. For clients, a malicious server that triggers a redirect to a crafted URL could exploit the URI validation gap. For servers, any client that can cause the server to emit a crafted response reason phrase could exploit the response splitting gap.
In vulnerable applications, where attacker controlled data is supplied to these fields, the attack is low-effort: injecting a CRLF sequence into a URI or reason phrase requires only a single crafted request. Successful exploitation can allow an attacker to smuggle additional HTTP requests past intermediaries or split HTTP responses, potentially bypassing WAFs or poisoning web caches. However, most applications are not vulnerable at all.
The risk can be mitigated by ensuring that all user-controlled input is sanitized before being used in HTTP start line components. However, this mitigation places the burden on application developers and is error-prone.
The issue is fixed by extending NIOHTTPRequestHeadersValidator to validate request URIs against the character set defined in RFC 9112 Section 3.2 and RFC 3986 Section 3, and to validate custom HTTP methods against the token grammar defined in RFC 9110. NIOHTTPResponseHeadersValidator is extended to validate custom response reason phrases against RFC 9112 Section 4. Applications that use these validator channel handlers — which are installed by default when using addHTTPClientHandlers() or addHTTPServerHandlers() — will reject invalid outbound messages with an HTTPParserError.invalidHeaderToken error rather than emitting them to the network.
SwiftNIO is grateful to @kuranikaran and @YLChen-007 for their reporting and assistance with the project's process.
SwiftNIO vulnerable to Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
NIOHTTP1 and projects using it for generating HTTP responses, including SwiftNIO, can be subject to a HTTP Response Injection attack. This occurs when a HTTP/1.1 server accepts user generated input from an incoming request and reflects it into a HTTP/1.1 response header in some form. A malicious user can add newlines to their input (usually in encoded form) and "inject" those newlines into the returned HTTP response.
This capability allows users to work around security headers and HTTP/1.1 framing headers by injecting entirely false responses or other new headers. The injected false responses may also be treated as the response to subsequent requests, which can lead to XSS, cache poisoning, and a number of other flaws.
This issue was resolved by adding a default channel handler that polices outbound headers. This channel handler is added by default to channel pipelines, but can be removed by users if they are doing this validation themselves.
iOS RTKit memory corruption — actively exploited in the wild
Memory corruption in RTKit exploited in the wild. Requires iOS 17.4+.
