How severe is CVE-2026-28975?

No CVSS score has been assigned to CVE-2026-28975 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2026-28975?

CVE-2026-28975 affects the following packages: github.com/apple/swift-nio-extras (SwiftURL). Ecosystems affected: SwiftURL.

How do I fix CVE-2026-28975?

Update github.com/apple/swift-nio-extras to 1.34.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-28975 is resolved across your whole dependency graph.

How do I detect CVE-2026-28975 in my SwiftURL dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/apple/swift-nio-extras, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-28975 if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is CVE-2026-28975 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-28975 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was CVE-2026-28975 published, and has it been updated?

CVE-2026-28975 was published on June 12, 2026 and was last updated on September 10, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 SwiftURL

Not in CISA KEV

CVE-2026-28975 — swift-nio-extras

CVE-2026-28975 is a security vulnerability in github.com/apple/swift-nio-extras. A fix is available for github.com/apple/swift-nio-extras — see the affected versions and patch details below.

NIOExtras: NIOHTTPRequestDecompressor ratio limit bypass via inflated Content-Length

Published

Jun 12, 2026

Updated

Sep 10, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Sep 10, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

📦github.com/apple/swift-nio-extras

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects SwiftURL packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦SwiftURL	`github.com/apple/swift-nio-extras`	all versions	1.34.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/apple/swift-nio-extras, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/apple/swift-nio-extras to 1.34.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-28975 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### 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 e

O3 Security · Impact-Aware SCA

Is CVE-2026-28975 in your dependencies?

Find it across SwiftURL, including transitive dependencies.

Scan my dependencies How O3 SCA works