CVE-2026-53659: High severity maven/org.http4k:http4k-core vulnerability
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
- Vulnerability introduced: 2618fe08f9 - Fix release: v6.49.0.0 - Background: CWE-409 — Improper Handling of Highly Compressed Data
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.http4k:http4k-coreto a version that resolves this vulnerability.Fixed in 6.49.0.0 - Upgrade
Upgrade
maven/org.http4k:http4k-coreto a version that resolves this vulnerability.Fixed in 5.42.0.0 - Upgrade
Upgrade
http4kto a version that resolves this vulnerability.Fixed in 4.51.0.0 - Upgrade
Upgrade
http4kto a version that resolves this vulnerability.Fixed in 5.42.0.0 - Upgrade
Upgrade
http4kto a version that resolves this vulnerability.Fixed in 6.49.0.0 - Configuration
For deployments that cannot upgrade immediately, rely on the built-in cap: oversized gzip-encoded request bodies sent through `ServerFilters.GZip` / `RequestFilters.GunZip` should return `413 Request Entity Too Large` (and decompressing elsewhere should throw `SizeLimitExceededException`).
http4k ServerFilters.GZip / RequestFilters.GunZip gzip request decompression size limit = 10MB (default cap) - Configuration
Replace `GZip` / `GunZip` filters with custom versions that wrap the decompressed `InputStream` in a size-limited reader (cap decompressed size to prevent decompression bombs).
http4k ServerFilters.GZip / RequestFilters.GunZip filter implementation = custom size-limited decompression - Compensating control
Strip gzip-encoded request support at the edge (CDN, reverse proxy, or load balancer) to prevent gzip-encoded requests from reaching the http4k server.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-53659?
CVE-2026-53659 has a severity rating of high, with a CVSS score of 7.5.
What impact does CVE-2026-53659 have on systems?
CVE-2026-53659 can lead to denial of service by allowing malicious gzip-encoded request bodies to consume excessive decompressed memory.
How do I fix CVE-2026-53659?
To fix CVE-2026-53659, update to the latest version of http4k that addresses this vulnerability.
Who is affected by CVE-2026-53659?
CVE-2026-53659 affects systems using the http4k library, specifically versions prior to the security fix.
What software is associated with CVE-2026-53659?
CVE-2026-53659 is associated with the http4k-core component of the maven/org.http4k package.