{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/products/http4k-core/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["http4k-core"],"_cs_severities":["high"],"_cs_tags":["denial-of-service","vulnerability","web-server"],"_cs_type":"advisory","_cs_vendors":["http4k"],"content_html":"\u003cp\u003eThe http4k library (http4k-core) contains a vulnerability in its \u003ccode\u003eServerFilters.GZip\u003c/code\u003e and \u003ccode\u003eRequestFilters.GunZip\u003c/code\u003e components, where incoming request bodies are decompressed without verifying the final, expanded size. This flaw, tracked as CVE-2026-53659, allows an attacker to send a maliciously crafted, highly compressed gzip request of only a few kilobytes. Upon processing, the request expands significantly within the JVM heap, leading to memory exhaustion and a complete denial-of-service for the affected server.\u003c/p\u003e\n\u003cp\u003eThis vulnerability has existed since 2017 and affects multiple versions across the v4, v5, and v6 branches. Because the library is widely used for building HTTP services, this poses a high risk to applications that expose endpoints accepting compressed inputs. Defenders must prioritize upgrading to the patched versions or implementing protective measures at the network edge to inspect or reject oversized request payloads.\u003c/p\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation results in service unavailability due to JVM OutOfMemory errors. Any application using the affected http4k filters to process incoming requests is susceptible to unauthenticated remote exploitation. Impact is restricted to availability (DoS); there is no evidence of remote code execution or data exfiltration associated with this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade \u003ccode\u003ehttp4k-core\u003c/code\u003e to the patched versions: 4.51.0.0, 5.42.0.0, or 6.49.0.0 immediately to apply the default 10MB decompression limit.\u003c/li\u003e\n\u003cli\u003eImplement request body size limits at the edge (Load Balancer, Reverse Proxy, or WAF) to drop excessively large or potentially malicious compressed requests before they reach the application layer.\u003c/li\u003e\n\u003cli\u003eFor legacy applications that cannot be updated, implement a custom filter in the http4k pipeline that restricts the size of the \u003ccode\u003eInputStream\u003c/code\u003e before decompression occurs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-08-18T00:46:52Z","date_published":"2026-08-18T00:46:52Z","id":"https://feed.craftedsignal.io/briefs/2026-08-http4k-dos/","summary":"The http4k library fails to limit the size of decompressed gzip data, allowing unauthenticated remote attackers to trigger JVM heap exhaustion via small, highly compressed payloads.","title":"Unbounded Gzip Decompression Denial of Service in http4k","url":"https://feed.craftedsignal.io/briefs/2026-08-http4k-dos/"}],"language":"en","title":"CraftedSignal Threat Feed - Http4k-Core","version":"https://jsonfeed.org/version/1.1"}