Prior to release 4.51.0.0, 5.42.0.0, and 6.49.0.0, the http4k ServerFilters.GZip, RequestFilters.GunZip and underlying Gzip decompression paths set no limit on the size of the uncompressed data. An unauthenticated client could send a small gzip-encoded request body that expands to gigabytes, exhausting the JVM heap and denying service to other clients. The vulnerability has been patched by incorporating SizeLimitedInputStream, which imposes a default 10 MiB limit and causes the filters to return a 413 Request Entity Too Large response or throw SizeLimitExceededException when exceeded.

The vulnerability affects any http4k installation using ServerFilters.GZip, RequestFilters.GunZip, or any of the underlying gzip decompression paths that predates the release of 4.51.0.0, 5.42.0.0, or 6.49.0.0. System administrators should verify the http4k version in use and list any applications built with these filters as vulnerable.

The CVSS score of 7.5 indicates high severity, and while an EPSS score is <1%, the possibility of exploit is real because an unauthenticated client can trigger the attack simply by sending a gzip request. No CISA KEV listing means it has not been confirmed as a known exploited vulnerability, but the lack of a limit creates an obvious attack surface. An attacker can use an unrestricted network connection to the http4k service to misuse the decompression logic and exhaust memory, leading to service degradation or crash.