CVE-2026-53659 in http4k
Summary
by MITRE • 09/14/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified within the http4k functional toolkit for Kotlin HTTP applications represents a classic resource exhaustion flaw stemming from unbounded decompression operations. Prior to versions 4.51.0.0, 5.42.0.0, and 6.49.0.0, critical components such as ServerFilters.GZip, RequestFilters.GunZip, and the underlying Gzip request-body decompression functions failed to impose any constraints on the size of data after it had been expanded from its compressed format. This architectural oversight allows an attacker to exploit the significant ratio between compressed and uncompressed data sizes inherent in gzip encoding. By crafting a maliciously small but highly compressible payload, an unauthenticated client can trigger a massive expansion of memory usage within the Java Virtual Machine heap upon decompression.
From a technical perspective, this flaw is categorized under CWE-770: Allocation of Resources Without Limits or Throttling and aligns with MITRE ATT&CK technique T1496: Resource Hijacking, specifically in the context of denial-of-service attacks via resource exhaustion. The absence of size validation means that the application processes incoming data without verifying whether the resulting decompressed stream fits within available memory resources. When a client submits a request containing a gzip-encoded body designed to expand into gigabytes of plaintext data, the JVM attempts to allocate contiguous or fragmented heap space for this inflated content. Since there is no upper bound check during the decompression process, the application continues allocating memory until it reaches its maximum heap size limit.
The operational impact of this vulnerability is severe and directly affects service availability. Once the JVM heap is exhausted by a single malicious request, the garbage collector struggles to reclaim space, leading to frequent full GC pauses or an immediate OutOfMemoryError crash. This state renders the application unresponsive not only to the attacking client but also to legitimate users attempting to access services hosted on the same instance. The denial of service extends beyond simple latency increases; it can result in complete application failure requiring a restart, thereby disrupting business operations and potentially causing data loss if transactions were in progress at the time of the crash.
The remediation strategy implemented in the fixed versions addresses this issue by introducing strict size limits on decompression streams using SizeLimitedInputStream. This component enforces a default maximum limit of 10 MiB for any decompressed content, effectively capping the memory footprint associated with gzip operations. For endpoints utilizing ServerFilters.GZip and RequestFilters.GunZip, exceeding this threshold results in an HTTP 413 Request Entity Too Large response, providing clear feedback to clients while preventing resource abuse. In other decompression paths where explicit filtering is not applied, the system now throws a SizeLimitExceededException upon detecting oversized payloads, allowing for graceful error handling rather than catastrophic memory failure.
To mitigate this vulnerability in environments that have not yet upgraded, administrators should consider implementing reverse proxy configurations or API gateways that enforce request body size limits before traffic reaches the http4k application layer. Additionally, custom filters can be developed to inspect and limit input sizes if upgrading is not immediately feasible. However, the most robust solution remains updating to version 4.51.0.0, 5.42.0.0, or 6.49.0.0 where these protections are natively integrated into the framework's core decompression logic. Regular security audits and static analysis tools should also be employed to detect similar patterns of unbounded resource allocation in custom HTTP handling code across the organization’s Kotlin-based infrastructure.