PT-2026-76889 · Maven · Org.Http4K:Http4K-Core
CVE-2026-53659
·
Published
2026-08-17
·
Updated
2026-08-17
CVSS v3.1
7.5
High
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
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/GunZipfilters with custom versions that wrap the decompressedInputStreamin 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
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Org.Http4K:Http4K-Core