CVE-2026-28975: 
Swift vulnerability analysis and mitigation

CVE-2026-28975 is a decompression ratio limit bypass vulnerability in Apple's swift-nio-extras library, specifically in the NIOHTTPRequestDecompressor component. When configured with the .ratio(N) decompression limit, the check incorrectly uses the attacker-controlled Content-Length HTTP header as the denominator instead of the actual number of compressed bytes received, effectively allowing a gzip bomb attack to bypass the configured protection. All versions of swift-nio-extras prior to 1.34.1 are affected. The vulnerability was published on May 21, 2026, with a patch released on June 12, 2026, and carries a CVSS v4 base score of 6.9 (Medium) (GitHub Advisory, Swift NIO Extras Advisory).

The root cause is a logic error in the decompression ratio enforcement code (CWE-409: Improper Handling of Highly Compressed Data; CWE-770: Allocation of Resources Without Limits or Throttling). When .ratio(N) is configured, the check evaluates decompressed > Content-Length * N rather than decompressed > compressedBytesReceived * N. Because Content-Length is supplied by the client, an attacker can set it to match the expected decompressed size, causing the check to evaluate as decompressed > decompressed * N, which is always false for any positive N, thus never triggering the limit. This is a distinct flaw from CVE-2020-9840 (GHSA-xhhr-p2r9-jmm7), which found that the .size limit checked compressed rather than decompressed bytes and recommended .ratio as a workaround — users who adopted that workaround are directly affected by this vulnerability (GitHub Advisory, Swift NIO Extras Advisory).

Successful exploitation allows an unauthenticated remote attacker to cause unbounded memory consumption on the server by repeatedly sending small, highly-compressed gzip payloads (gzip bombs) with falsified Content-Length headers. Gzip payloads with highly repetitive data can achieve amplification ratios of several hundred to one, and across repeated requests this enables sustained memory amplification far exceeding configured limits with no error raised, potentially resulting in denial of service. There is no impact on confidentiality or integrity; the vulnerability is limited to availability of the affected system (GitHub Advisory).

No public exploit code or evidence of in-the-wild exploitation has been reported for CVE-2026-28975. The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially exploitable by any network-accessible attacker against a vulnerable server. The EPSS score is approximately 0.042% (13th percentile), indicating a low current probability of exploitation in the next 30 days. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Identify target: Locate a server using swift-nio-extras versions prior to 1.34.1 with NIOHTTPRequestDecompressor configured using .ratio(N).
2. Craft gzip bomb: Create a small, highly-compressed gzip payload containing highly repetitive data (e.g., a large block of repeated bytes compressed to a few kilobytes), capable of expanding to hundreds of megabytes upon decompression.
3. Falsify Content-Length header: Set the HTTP Content-Length header in the request to match the decompressed size of the payload (e.g., if the payload decompresses to 500 MB, set Content-Length: 524288000).
4. Send the request: Transmit the crafted HTTP request with the compressed body and inflated Content-Length to the target server. The ratio check evaluates decompressed > Content-Length * N, which becomes decompressed > decompressed * N — always false — so the payload is accepted and fully decompressed.
5. Repeat for sustained DoS: Send multiple such requests in rapid succession to sustain memory amplification, potentially exhausting server memory and causing denial of service (GitHub Advisory, Swift NIO Extras Advisory).

• Network: Repeated HTTP requests with a very small body size but an unusually large Content-Length header value; requests with compressed content-encoding (e.g., Content-Encoding: gzip) where the declared Content-Length is orders of magnitude larger than the actual transmitted bytes.
• Logs: Server access logs showing requests where Content-Length values are abnormally large relative to actual request body size; repeated requests to the same endpoint from the same or rotating source IPs with compressed payloads.
• Process/System: Rapid and sustained growth in server process memory usage (RSS) without a corresponding increase in legitimate traffic; out-of-memory (OOM) events or process crashes on the Swift NIO server process.

The vulnerability is fixed in swift-nio-extras version 1.34.1, which unifies the request and response decompressor implementations to accumulate actual compressed bytes received (compressedLength += part.readableBytes) rather than relying on the Content-Length header. As an immediate workaround for applications that cannot upgrade, switch from .ratio(N) to .size(N) to enforce a fixed upper bound on decompressed output — the .size limit does not reference Content-Length and is not affected by this vulnerability. Upgrading to 1.34.1 is the recommended long-term solution (GitHub Advisory, Swift NIO Extras Advisory).

The vulnerability was reported by researcher @nathanielmiller23 and published by Apple Swift NIO maintainer Lukasa via the GitHub Security Advisory process. A security release announcement was made on the Swift Forums covering SwiftNIO 2.100.0, SwiftNIO HTTP/2 1.44.0, and SwiftNIO Extras 1.34.1 (Swift Forums). No significant broader media coverage or notable community controversy has been observed beyond the standard advisory process.