CVE-2026-53659: 
Java vulnerability analysis and mitigation

CVE-2026-53659 is a decompression bomb (zip bomb) vulnerability in the http4k Kotlin HTTP toolkit affecting the ServerFilters.GZip and RequestFilters.GunZip filters in the org.http4k:http4k-core Maven package. The flaw allows any unauthenticated remote attacker to send a small gzip-encoded request body (on the order of kilobytes) that decompresses to gigabytes, exhausting the JVM heap and causing a denial of service. The vulnerability was introduced on 2017-08-01 (commit 2618fe08f9) and persisted for approximately nine years. Affected versions include v4.x up to 4.48.2.0, v5.x from 5.0.0.0 to before 5.42.0.0, and v6.x from 6.0.0.0 to before 6.49.0.0. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, http4k Advisory).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification): the ServerFilters.GZip and RequestFilters.GunZip filters, along with the underlying Gzip decompression functions, read the decompressed output stream without enforcing any size limit. An attacker crafts a valid gzip payload with an extremely high compression ratio — a classic "decompression bomb" — and submits it as a gzip-encoded HTTP request body. Upon receipt, the server decompresses the payload without bound, rapidly consuming all available JVM heap memory. No authentication, special privileges, or user interaction are required; any network-reachable http4k server endpoint that accepts Content-Encoding: gzip is vulnerable (GitHub Advisory, http4k Advisory).

Successful exploitation results in complete denial of service for the affected http4k server instance: JVM heap exhaustion causes the server to become unresponsive or crash, denying service to all legitimate clients. The impact is limited to availability — there is no confidentiality or integrity impact, and the vulnerability's scope is unchanged (it does not enable lateral movement or data exfiltration). Any application built on http4k that exposes gzip-accepting endpoints is at risk, including APIs and web services in production environments (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is trivially exploitable in concept — decompression bomb payloads are well-understood and easy to construct using standard tools — and requires no authentication, making it accessible to any network attacker. The CVE is currently in "Reserved" status and has not been added to the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported.

1. Identify target: Locate an http4k server (versions v4.x ≤ 4.48.2.0, v5.x < 5.42.0.0, or v6.x < 6.49.0.0) that accepts gzip-encoded request bodies via ServerFilters.GZip or RequestFilters.GunZip.
2. Craft decompression bomb: Create a gzip-compressed payload with an extremely high compression ratio (e.g., compress gigabytes of repeated null bytes or ASCII characters into a few kilobytes using standard tools like gzip or Python's gzip module).
3. Send malicious request: Submit an HTTP POST (or other body-bearing method) request to any endpoint on the target server with the header Content-Encoding: gzip and the crafted bomb as the request body.
4. Trigger heap exhaustion: The server's GZip/GunZip filter decompresses the payload without size limits, rapidly consuming JVM heap memory until an OutOfMemoryError is thrown, crashing or hanging the server process and denying service to all other clients (GitHub Advisory, http4k Advisory).

• Network: Inbound HTTP requests with Content-Encoding: gzip headers containing unusually small body sizes (kilobytes) sent to application endpoints; repeated such requests from the same source IP.
• Logs: Application or access logs showing requests with Content-Encoding: gzip immediately followed by server errors, JVM crash logs (hs_err_pid*.log), or OutOfMemoryError stack traces in application logs.
• Process/JVM: Sudden spike in JVM heap usage to near-maximum capacity visible in JVM monitoring (e.g., JMX, Prometheus JVM metrics); garbage collection logs showing continuous full GC cycles with no heap recovery; JVM process crash or restart.
• System: Operating system OOM killer events in system logs (Linux: dmesg or /var/log/syslog showing java process killed); unexpected application restarts or container/pod restarts in orchestration platforms.

Upgrade org.http4k:http4k-core to the following patched versions: 6.49.0.0 (Community/v6.x), 5.42.0.0 (Enterprise LTS/v5.x), or 4.51.0.0 (Enterprise LTS/v4.x — contact enterprise@http4k.org). The fix caps gzip decompression at 10MB by default; oversized requests via ServerFilters.GZip/RequestFilters.GunZip now return 413 Request Entity Too Large, and direct decompression calls throw SizeLimitExceededException. For deployments that cannot upgrade immediately, replace the GZip/GunZip filters with custom implementations that wrap the decompressed InputStream in a size-limited reader, or strip gzip-encoded request support at the edge (CDN, reverse proxy, or load balancer) (GitHub Advisory, http4k Release).

The advisory was published by http4k maintainer daviddenton on June 16, 2026, and formally published to the GitHub Advisory Database on August 17, 2026. The http4k project proactively disclosed the vulnerability with detailed patch notes and workaround guidance in the v6.49.0.0 release changelog (http4k Release). No significant broader media coverage or notable external researcher commentary has been identified at this time.