Summary
NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length
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.
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.
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.
The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-28975? CVE-2026-28975 is a medium-severity allocation of resources without limits or throttling vulnerability in github.com/apple/swift-nio-extras (swift), affecting versions < 1.34.1. It is fixed in 1.34.1. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
- Which versions of github.com/apple/swift-nio-extras are affected by CVE-2026-28975? github.com/apple/swift-nio-extras (swift) versions < 1.34.1 is affected.
- Is there a fix for CVE-2026-28975? Yes. CVE-2026-28975 is fixed in 1.34.1. Upgrade to this version or later.
- Is CVE-2026-28975 exploitable, and should I be worried? Whether CVE-2026-28975 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-28975 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-28975? Upgrade
github.com/apple/swift-nio-extrasto 1.34.1 or later.