Answer in brief
CVE-2026-53659 records a High severity (CVSS 7.5) vulnerability in http4k: Unbounded gzip decompression in `ServerFilters.GZip` / `RequestFilters.GunZip` allowed memory-exhaustion DoS. The current sources do not mark it as known exploited. The current feed maps http4k/http4k (generic), org.http4k:http4k-core (maven), org.http4k:http4k-core (maven), org.http4k:http4k-core (maven) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps http4k/http4k (generic), org.http4k:http4k-core (maven), org.http4k:http4k-core (maven), org.http4k:http4k-core (maven) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| http4k/http4kgeneric | < 4.51.0.0 || >= 5.0.0.0, < 5.42.0.0 || >= 6.0.0.0, < 6.49.0.0 | Not reported |
| org.http4k:http4k-coremaven | >=5.0.0.0,<5.42.0.0 | 5.42.0.0 |
| org.http4k:http4k-coremaven | <=4.48.2.0 | Not reported |
| org.http4k:http4k-coremaven | >=6.0.0.0,<6.49.0.0 | 6.49.0.0 |
| org.http4k:http4k-coremaven | >=6.0.0.0 <6.49.0.0 | 6.49.0.0 |
| org.http4k:http4k-coremaven | >=5.0.0.0 <5.42.0.0 | 5.42.0.0 |
| org.http4k:http4k-coremaven | >=0 | Not reported |
Published upstream
Sep 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 17, 2026
http4k is a functional toolkit for Kotlin HTTP applications. Prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0, ServerFilters.GZip, RequestFilters.GunZip, and the underlying Gzip request-body decompression functions impose no limit on decompressed size. An unauthenticated client can send a small gzip-encoded request body that expands to gigabytes, exhausting the JVM heap and denying service to other clients. The fix uses SizeLimitedInputStream to enforce a default 10 MiB limit, causes ServerFilters.GZip and RequestFilters.GunZip to return 413 Request Entity Too Large, and causes other decompression paths to throw SizeLimitExceededException. This issue is fixed in versions 4.51.0.0, 5.42.0.0, and 6.49.0.0.
Quoted source text, attributed separately from HOL analysis.