Description

http4k is a functional toolkit for Kotlin HTTP applications. Prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0, ServerFilters.GZip, RequestFilters.GunZip, and the underlying Gzip request-body decompression functions impose no limit on decompressed size. An unauthenticated client can send a small gzip-encoded request body that expands to gigabytes, exhausting the JVM heap and denying service to other clients. The fix uses SizeLimitedInputStream to enforce a default 10 MiB limit, causes ServerFilters.GZip and RequestFilters.GunZip to return 413 Request Entity Too Large, and causes other decompression paths to throw SizeLimitExceededException. This issue is fixed in versions 4.51.0.0, 5.42.0.0, and 6.49.0.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T18:17:51.610Z",
  "pubdate": "2026-09-14T18:17:51.610Z",
  "executiveSummary": "The http4k functional toolkit is susceptible to a Denial-of-Service (DoS) vulnerability arising from unbounded Gzip request-body decompression.\nThe vulnerability exists within the ServerFilters.GZip and RequestFilters.GunZip components, which fail to constrain the size of decompressed payloads.\nAn unauthenticated attacker can exploit this by transmitting a maliciously crafted, highly compressed Gzip request body. Upon decompression, the payload expands significantly, leading to heap exhaustion and JVM instability.\nThis vulnerability impacts http4k versions prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0.\nThe primary risk is service unavailability, as the exhaustion of heap memory forces the application to crash or become unresponsive to legitimate client traffic.\nSuccessful exploitation requires no prior authentication and can be executed over the network by any actor capable of initiating a standard HTTP request to the affected server.",
  "technicalDetails": "The vulnerability resides in the request-body decompression logic within http4k, specifically affecting the ServerFilters.GZip and RequestFilters.GunZip filters, alongside underlying decompression utilities.\nThe root cause is a lack of input validation regarding the expansion ratio of compressed data. The decompression process operates on an 'as-needed' basis without enforcing a maximum limit on the total size of the output stream.\nAn attacker can leverage the Gzip algorithm's compression efficiency to send a relatively small request body (a 'decompression bomb'). When the server processes this stream, the decompression function continues to allocate heap space to store the expanded data until the JVM reaches its capacity.\nThe attack flow proceeds as follows: 1) The attacker identifies an endpoint utilizing the vulnerable ServerFilters.GZip or RequestFilters.GunZip components. 2) The attacker crafts a Gzip-encoded payload containing a highly repetitive data pattern designed for extreme expansion. 3) The attacker transmits this payload in an HTTP request. 4) The server attempts to decompress the body, consuming excessive JVM heap memory. 5) The JVM becomes unstable due to memory exhaustion, resulting in a denial-of-service condition for all concurrent operations.\nThis vulnerability affects all versions of http4k prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0. The lack of an upper bound on decompressed data provides a direct vector for resource exhaustion.\nThe fix introduced in the specified versions implements SizeLimitedInputStream. This mechanism enforces a default 10 MiB limit on the decompressed data. If this threshold is exceeded, the server now terminates the stream, causing ServerFilters.GZip and RequestFilters.GunZip to return an HTTP 413 Request Entity Too Large status code, while other decompression paths throw a SizeLimitExceededException, effectively neutralizing the heap exhaustion vector."
}