swift-nio-extras CVE-2026-28975
MEDIUM
GHSA-6ph5-fww6-vfwv
Severity by source
Network-reachable, no auth or user interaction needed; only availability is impacted via unbounded memory exhaustion.
Lifecycle Timeline
2DescriptionCVE.org
Impact
When NIOHTTPRequestDecompressor is configured with .ratio(N), the decompression limit is enforced using the Content-Length header value from the incoming request rather than the actual number of compressed bytes received. Since Content-Length is attacker-controlled, a malicious client can supply an inflated value that causes the ratio check to always pass, effectively disabling the configured decompression limit.
This allows an attacker to send a small, highly-compressed payload (a "gzip bomb") with a falsified Content-Length header to bypass the ratio-based protection entirely. The server will decompress the payload without limit, consuming unbounded memory and potentially causing denial of service.
For example, a gzip payload containing highly repetitive data can achieve amplification ratios of several hundred to one. Under .ratio(10) such a payload should be rejected, but if the attacker sets Content-Length to match the decompressed size, the check evaluates decompressed > decompressed * 10 which is always false, and the payload is accepted without error.
Across repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.
Relationship to CVE-2020-9840
GHSA-xhhr-p2r9-jmm7 (CVE-2020-9840) found that the .size limit checked compressed rather than decompressed bytes and recommended .ratio as a workaround. This advisory identifies a distinct flaw in the .ratio limit itself: it uses the attacker-supplied Content-Length header as the denominator rather than actual consumed compressed bytes. The two vulnerabilities are in the same decompression limit enforcement code but involve non-overlapping logic errors.
Users who followed the CVE-2020-9840 workaround by switching to .ratio(N) are affected by this vulnerability.
Patches
Fixed in swift-nio-extras 1.34.1. The fix unifies the request and response decompressor implementations so that both accumulate actual compressed bytes received (compressedLength += part.readableBytes) rather than relying on any header-supplied value.
Workarounds
Use .size(N) instead of .ratio(N) if a fixed upper bound on decompressed output is acceptable for the application. The .size limit is not affected by this vulnerability as it does not reference Content-Length.
Credits
NIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.
AnalysisAI
Denial of service via gzip bomb in swift-nio-extras NIOHTTPRequestDecompressor affects any Swift server using the .ratio(N) decompression limit, allowing unauthenticated remote attackers to exhaust server memory without limit. The ratio enforcement logic incorrectly uses the attacker-supplied Content-Length request header as the denominator of the compression ratio check instead of the actual number of compressed bytes received, making the check trivially bypassable. No public exploit code has been identified at time of analysis, but the bypass technique is straightforward and requires no special tooling - any HTTP client capable of crafting a gzip payload with a falsified Content-Length header can trigger it repeatedly to sustain memory amplification.
Technical ContextAI
swift-nio-extras is Apple's supplementary library for Swift NIO, a non-blocking I/O framework for building high-performance network servers in Swift. The affected component is NIOHTTPRequestDecompressor, which transparently decompresses incoming HTTP request bodies. CWE-409 (Improper Handling of Highly Compressed Data - 'Zip Bomb') describes the root cause class: the decompressor fails to account for adversarially crafted compression ratios. Specifically, the .ratio(N) guard evaluates decompressedBytes > Content-Length * N; since Content-Length is an HTTP header under attacker control, setting it to the expected decompressed size makes the check read as decompressed > decompressed * N, which is always false for positive N. This is distinct from CVE-2020-9840, where the .size limit incorrectly measured compressed rather than decompressed bytes - Apple's own advisory for that earlier CVE recommended .ratio(N) as a workaround, meaning users who followed that guidance are now directly affected by this vulnerability. The fix in 1.34.1 accumulates actual bytes received via compressedLength += part.readableBytes, eliminating any reliance on header-supplied values. Affected package: pkg:swift/github.com_apple_swift-nio-extras versions prior to 1.34.1.
RemediationAI
The primary fix is to upgrade swift-nio-extras to version 1.34.1 or later, which is confirmed patched per the vendor advisory at https://github.com/apple/swift-nio-extras/security/advisories/GHSA-6ph5-fww6-vfwv. The patch unifies request and response decompressor logic so that actual compressed bytes received are accumulated rather than using the Content-Length header. If an immediate upgrade is not feasible, the documented workaround is to switch from .ratio(N) to .size(N) in the NIOHTTPRequestDecompressor configuration - the .size(N) limit caps absolute decompressed output bytes and does not reference any header value, making it immune to this bypass. The trade-off of .size(N) is that it requires knowing an acceptable fixed upper bound on decompressed body size in advance, which may reject legitimate large payloads that .ratio was intended to permit. Applications that switched to .ratio(N) specifically as a CVE-2020-9840 workaround should treat this upgrade as urgent, since their current configuration was adopted under a now-invalid security assumption.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today