Start for Free
HIGH 7.5 Maven

http4k: Unbounded gzip decompression in `ServerFilters.GZip` / `RequestFilters.GunZip` allowed memory-exhaustion DoS

GHSA-g4w2-6h2r-3m3w · CVE-2026-53659

Published · Modified

AI SAST

Find this class of vulnerability in your own code

Corgea's AI-native static analysis detects vulnerabilities like this one across your repositories, ranks them by exploitability, and returns review-ready fixes.

Explore AI SAST Explore dependency scanning →

Description

Impact

ServerFilters.GZip and RequestFilters.GunZip (and the underlying Gzip functions used to decompress request bodies) did not impose any cap on the decompressed size. A small malicious gzip-encoded request body (on the order of kilobytes) could decompress to gigabytes, exhausting the JVM heap and denying service to other clients.

Who is affected: any http4k server that accepts gzip-encoded requests via ServerFilters.GZip or RequestFilters.GunZip. Exploitable by any unauthenticated client. The vulnerability was introduced on 2017-08-01 (commit 2618fe08f9) and was present for ~9 years.

Patches

Line Fixed in Edition
v6.x (Community) 6.49.0.0 Community
v5.x (LTS) 5.42.0.0 Enterprise — contact enterprise@http4k.org
v4.x (LTS) 4.51.0.0 Enterprise — contact enterprise@http4k.org

The fix caps decompression at 10MB by default; oversized requests through ServerFilters.GZip / RequestFilters.GunZip now return 413 Request Entity Too Large, and decompressing elsewhere throws SizeLimitExceededException. The keyed hmacSHA256 helper and other safe paths are unaffected.

Workarounds

For deployments that cannot upgrade immediately:

  • Replace the GZip / GunZip filters with custom versions 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).

References

References

More Maven vulnerabilities

Ready to move

Start Securing

Start for Free Get Demo

Free, no credit card | First findings in minutes