CVE-2026-53659: http4k unbounded gzip decompression denial of service

CVE-2026-53659 · Severity: high · CVSS 7.5 · Published 2026-09-14

http4k is a popular open-source HTTP toolkit used to build web applications and services. The gzip decompression feature in http4k failed to limit how large a decompressed payload could grow, allowing attackers to send tiny compressed files that explode into gigabytes when decompressed. This would consume all available JVM memory, crashing the service and preventing legitimate users from accessing the application. Any unauthenticated attacker on the network could exploit this with a single malicious request.

Technologies: Http4k-Core. Vendors: Http4k, Maven.

Quick answers

Is CVE-2026-53659 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-53659 being exploited in the wild.
How severe is CVE-2026-53659?
High severity, with a CVSS score of 7.5, published 14 September 2026.
Which products and versions are affected?
Http4k-Core < 4.51.0.0, >= 5.0.0.0 < 5.42.0.0, >= 6.0.0.0 < 6.49.0.0; org.http4k:http4k-core (Maven) ECOSYSTEM:introduced=6.0.0.0,fixed=6.49.0.0.
Is there a fix for CVE-2026-53659?
Yes. org.http4k:http4k-core (Maven): upgrade to 6.49.0.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-53659 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-53659?
Check whether you run Http4k-Core or org.http4k:http4k-core (Maven) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • org.http4k:http4k-core (Maven): upgrade to 6.49.0.0 or later
    # set org.http4k:http4k-core to 6.49.0.0 in your pom.xml or build.gradle

Technical details

The vulnerability is an improper handling of highly compressed data (CWE-409). The ServerFilters.GZip and RequestFilters.GunZip filters (along with underlying Gzip decompression functions) did not impose any limit on decompressed output size. An attacker could craft a gzip-compressed request body with a very high compression ratio—on the order of kilobytes that decompresses to gigabytes—exhausting the JVM heap and causing denial of service. The vulnerability is exploitable by any unauthenticated network client and requires no special privileges or user interaction. The fix caps decompression at 10MB by default; requests exceeding this limit now return HTTP 413 (Request Entity Too Large) or throw SizeLimitExceededException during manual decompression.

Affected products

  • http4k http4k-core < 4.51.0.0, >= 5.0.0.0 < 5.42.0.0, >= 6.0.0.0 < 6.49.0.0

Identifiers

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

Timeline

  • 2026-08-17: disclosed: Public disclosure via GitHub Advisory GHSA-g4w2-6h2r-3m3w
  • 2026-05-30: patched: Fix released in v6.49.0.0 (also v5.42.0.0 Enterprise and v4.51.0.0 Enterprise)
  • 2017-08-01: other: Vulnerability introduced in commit 2618fe08f9; present for ~9 years

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.