{"id":"CVE-2026-28975","aliases":["GHSA-6ph5-fww6-vfwv"],"status":"published","title":"NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length","description":"### Impact\n\nWhen `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.\n\nThis 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.\n\nFor 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 \u003e decompressed * 10` which is always false, and the payload is accepted without error.\n\nAcross repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.\n\n### Relationship to CVE-2020-9840\n\nGHSA-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.\n\nUsers who followed the CVE-2020-9840 workaround by switching to `.ratio(N)` are affected by this vulnerability.\n\n### Patches\n\nFixed 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.\n\n### Workarounds\n\nUse `.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`.\n\n### Credits\n\nNIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.","severity":{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-409","CWE-770"],"published":"2026-06-12T15:08:04Z","modified":"2026-09-10T03:51:07Z","fixes":[{"ecosystem":"SwiftURL","package":"github.com/apple/swift-nio-extras","fixed_in":["1.34.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"SwiftURL","package":"github.com/apple/swift-nio-extras","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.34.1"}]}]},{"source":"osv","ecosystem":"SwiftURL","package":"github.com/apple/swift-nio-extras","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.34.1"}]}]}],"references":[{"url":"https://github.com/apple/swift-nio-extras/security/advisories/GHSA-6ph5-fww6-vfwv","tags":["web"]},{"url":"https://github.com/advisories/GHSA-6ph5-fww6-vfwv"},{"url":"https://github.com/apple/swift-nio-extras","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-6ph5-fww6-vfwv","title":"NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length","description":"### Impact\n\nWhen `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.\n\nThis 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.\n\nFor 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 \u003e decompressed * 10` which is always false, and the payload is accepted without error.\n\nAcross repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.\n\n### Relationship to CVE-2020-9840\n\nGHSA-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.\n\nUsers who followed the CVE-2020-9840 workaround by switching to `.ratio(N)` are affected by this vulnerability.\n\n### Patches\n\nFixed 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.\n\n### Workarounds\n\nUse `.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`.\n\n### Credits\n\nNIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.","status":"published","published":"2026-06-12T15:08:04Z","modified":"2026-06-12T15:08:06Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-409","CWE-770"],"updated_at":"2026-11-02T14:40:26.12116Z"}],"osv":[{"id":"GHSA-6ph5-fww6-vfwv","title":"NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length","description":"### Impact\n\nWhen `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.\n\nThis 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.\n\nFor 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 \u003e decompressed * 10` which is always false, and the payload is accepted without error.\n\nAcross repeated requests, this allows sustained memory amplification far exceeding the configured limits with no error raised.\n\n### Relationship to CVE-2020-9840\n\nGHSA-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.\n\nUsers who followed the CVE-2020-9840 workaround by switching to `.ratio(N)` are affected by this vulnerability.\n\n### Patches\n\nFixed 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.\n\n### Workarounds\n\nUse `.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`.\n\n### Credits\n\nNIOExtras is grateful to @nathanielmiller23 for their reporting and assistance with the process.","status":"published","published":"2026-06-12T15:08:04Z","modified":"2026-09-10T03:51:07.965469024Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-409","CWE-770"],"updated_at":"2026-11-02T15:46:39.965326Z"}]}}