CVE-2026-53659: http4k Gzip Decompression DOS Vulnerability

CVE-2026-53659 Overview

http4k is a functional toolkit for building Kotlin HTTP applications. A denial-of-service vulnerability affects http4k versions prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0. The flaw exists in ServerFilters.GZip, RequestFilters.GunZip, and the underlying gzip request-body decompression functions, which impose no limit on decompressed size. An unauthenticated attacker can transmit a small gzip-encoded request body that expands to gigabytes, exhausting the Java Virtual Machine (JVM) heap and preventing service to legitimate clients. The vulnerability is categorized under [CWE-409] (Improper Handling of Highly Compressed Data), commonly known as a decompression bomb or zip bomb attack.

Critical Impact
An unauthenticated remote attacker can crash any http4k service accepting gzip-encoded requests by sending a small compressed payload that expands to gigabytes in memory.

Affected Products

http4k versions prior to 4.51.0.0
http4k versions prior to 5.42.0.0
http4k versions prior to 6.49.0.0

Discovery Timeline

2026-09-14 - CVE-2026-53659 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-53659

Vulnerability Analysis

The vulnerability resides in http4k's request-body decompression pipeline. Both ServerFilters.GZip and RequestFilters.GunZip accept gzip-compressed request bodies and decompress them fully into memory. Neither filter validates the size of the decompressed output.

An attacker crafts a small gzip payload built from highly repetitive input. Gzip achieves compression ratios exceeding 1000:1 on such data. A payload of a few kilobytes can expand to several gigabytes during decompression.

The unbounded expansion allocates heap memory until the JVM exhausts available space. This triggers OutOfMemoryError conditions, halts request processing, and denies service to concurrent clients sharing the process.

Root Cause

The decompression functions in Gzip.kt wrapped gzip input streams without applying a byte-count limit. The gzip stream reader continued to inflate data as long as compressed bytes were available, with no upstream check on the resulting size. This design assumed input bodies would be size-bounded elsewhere in the request pipeline, which is not the case for gzip-encoded content.

Attack Vector

The attack requires only network reachability to an http4k endpoint that installs ServerFilters.GZip or accepts Content-Encoding: gzip. No authentication or user interaction is needed. An attacker sends an HTTP request with a Content-Encoding: gzip header and a small crafted payload constructed to expand dramatically during inflation.

text

 import org.http4k.core.Request
 import org.http4k.core.Response
 import org.http4k.core.StreamBody
+import org.http4k.util.SizeLimitedInputStream
 import java.io.ByteArrayInputStream
 import java.io.ByteArrayOutputStream
 import java.io.IOException

Source: http4k security patch commit 9f9e02f

The patch introduces SizeLimitedInputStream, which throws SizeLimitExceededException when decompressed output exceeds the configured limit.

text

 import org.http4k.core.Request
 import org.http4k.core.Response
 import org.http4k.core.Status.Companion.BAD_REQUEST
+import org.http4k.core.Status.Companion.REQUEST_ENTITY_TOO_LARGE
 import org.http4k.core.Uri
 import org.http4k.core.with
 import org.http4k.filter.GzipCompressionMode.Memory
+import org.http4k.util.SizeLimitExceededException

 object RequestFilters {

Source: http4k RequestFilters patch commit 9f9e02f

RequestFilters now imports REQUEST_ENTITY_TOO_LARGE and SizeLimitExceededException, returning HTTP 413 when a bounded stream is exceeded.

Detection Methods for CVE-2026-53659

Indicators of Compromise

HTTP requests containing Content-Encoding: gzip with unusually small Content-Length values followed by process memory spikes.
JVM OutOfMemoryError or GC overhead limit exceeded entries in application logs correlated with gzip request handling.
Sudden latency spikes or thread starvation in http4k services immediately after receiving compressed POST or PUT requests.
Repeated 5xx responses or process restarts on services exposing endpoints that accept compressed bodies.

Detection Strategies

Inspect access logs for requests with Content-Encoding: gzip where Content-Length is below 100 KB but produce sustained high heap allocation.
Correlate JVM garbage collection metrics with inbound request timestamps to identify decompression-triggered memory pressure.
Enumerate dependency manifests such as build.gradle or pom.xml for vulnerable http4k versions before the fixed releases.

Monitoring Recommendations

Instrument JVM heap and old-generation memory metrics with alerts on abnormal growth rates during HTTP processing.
Monitor upstream reverse proxies for anomalous compression-ratio patterns on inbound bodies.
Track HTTP 413 response counts after patching to identify attackers probing for the vulnerability.

How to Mitigate CVE-2026-53659

Immediate Actions Required

Upgrade http4k to version 4.51.0.0, 5.42.0.0, or 6.49.0.0 depending on the major version branch in use.
Audit all services using ServerFilters.GZip or RequestFilters.GunZip and prioritize internet-facing deployments.
Deploy a reverse proxy or web application firewall rule to cap raw request body sizes ahead of the JVM.

Patch Information

The fix is available in http4k versions 4.51.0.0, 5.42.0.0, and 6.49.0.0. The patch adds SizeLimitedInputStream with a default 10 MiB limit. ServerFilters.GZip and RequestFilters.GunZip return HTTP 413 Request Entity Too Large when the limit is exceeded. Other decompression paths throw SizeLimitExceededException. Full details are available in the GitHub Security Advisory GHSA-g4w2-6h2r-3m3w and http4k release 6.49.0.0.

Workarounds

Remove ServerFilters.GZip and RequestFilters.GunZip from filter chains until upgrading is possible.
Enforce strict request-body size limits at an upstream proxy such as Nginx, HAProxy, or a WAF before requests reach http4k.
Reject requests carrying Content-Encoding: gzip at the edge for endpoints that do not require compressed input.

bash

# Example Gradle dependency update to a fixed version
dependencies {
    implementation("org.http4k:http4k-core:6.49.0.0")
}

# Example Nginx client body size enforcement
# nginx.conf snippet
client_max_body_size 1m;