GHSA-g4w2-6h2r-3m3w http4k: Unbounded gzip decompression in `ServerFilters.GZip` / `RequestFilters.GunZip` allowed memory-exhaustion DoS

• Maven org.http4k:http4k-core: >= 6.0.0.0, < 6.49.0.0 → fixed in 6.49.0.0 • Maven org.http4k:http4k-core: >= 5.0.0.0, < 5.42.0.0 → fixed in 5.42.0.0 • Maven org.http4k:http4k-core: <= 4.48.2.0 (no fix yet)

Impact `ServerFilters.GZip` and `RequestFilters.GunZip` (and the underlying `Gzip` functions used to decompress request bodies) did not impose any cap on the decompressed size. A small malicious gzip-encoded request body (on the order of kilobytes) could decompress to gigabytes, exhausting the JVM heap and denying service to other clients. Who is affected: any http4k server that accepts gzip-encoded requests via `ServerFilters.GZip` or `RequestFilters.GunZip`. Exploitable by any unauthenticated client. The vulnerability was introduced on 2017-08-01 (commit `2618fe08f9`) and was present for ~9 years. Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | 6.49.0.0 | Community | | v5.x (LTS) | 5.42.0.0 | Enterprise — contact [email protected] | | v4.x (LTS) | 4.51.0.0 | Enterprise — contact [email protected] | The fix caps decompression at 10MB by default; oversized requests through `ServerFilters.GZip` / `RequestFilters.GunZip` now return `413 Request Entity Too Large`, and decompressing elsewhere throws `SizeLimitExceededException`. The keyed `hmacSHA256` helper and other safe paths are unaffected. Workarounds For deployments that cannot upgrade immediately: • Replace the `GZip` / `GunZip` filters with custom versions that wrap the decompressed `InputStream` in a size-limited reader, or • Strip gzip-encoded request support at the edge (CDN, reverse proxy, or load balancer). References • Vulnerability introduced: `2618fe08f9` • Fix release: v6.49.0.0 • Background: CWE-409 — Improper Handling of Highly Compressed Data