Executive brief
http4k is a popular open-source HTTP toolkit used to build web applications and services. The gzip decompression feature in http4k failed to limit how large a decompressed payload could grow, allowing attackers to send tiny compressed files that explode into gigabytes when decompressed. This would consume all available JVM memory, crashing the service and preventing legitimate users from accessing the application. Any unauthenticated attacker on the network could exploit this with a single malicious request.
Technical details
The vulnerability is an improper handling of highly compressed data (CWE-409). The ServerFilters.GZip and RequestFilters.GunZip filters (along with underlying Gzip decompression functions) did not impose any limit on decompressed output size. An attacker could craft a gzip-compressed request body with a very high compression ratio—on the order of kilobytes that decompresses to gigabytes—exhausting the JVM heap and causing denial of service. The vulnerability is exploitable by any unauthenticated network client and requires no special privileges or user interaction. The fix caps decompression at 10MB by default; requests exceeding this limit now return HTTP 413 (Request Entity Too Large) or throw SizeLimitExceededException during manual decompression.
Affected products
- http4k http4k-core < 4.51.0.0, >= 5.0.0.0 < 5.42.0.0, >= 6.0.0.0 < 6.49.0.0
Timeline
- 2026-08-17: disclosed: Public disclosure via GitHub Advisory GHSA-g4w2-6h2r-3m3w
- 2026-05-30: patched: Fix released in v6.49.0.0 (also v5.42.0.0 Enterprise and v4.51.0.0 Enterprise)
- 2017-08-01: other: Vulnerability introduced in commit 2618fe08f9; present for ~9 years