Advisories for Maven/Org.http4k/Http4k-Core package

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 …

The previous BasicCookieStorage did not enforce RFC 6265 scoping rules around cookie domain, path, and Secure attribute. A client using a single storage instance to talk to multiple origins could have cookies leak across domains, or have Secure cookies sent over plain HTTP — the deprecation message states it bluntly: "BasicCookieStorage has no domain/path/scheme scoping and leaks cookies across origins. Use DefaultCookieStorage instead." Who is affected: any client using BasicCookieStorage …

reverseProxy() and reverseProxyRouting() matched configured vhosts by substring on the Host header (Contains matcher) by default. The intended use of these functions in http4k is outbound dispatch (e.g. matching AWS service subdomains, per the Contains docstring) and test-time composition of fake backend networks. In either of those contexts the matched Host is set by the calling application, not by an external attacker, so the loose match has no exploit surface. …

The HmacSha256 class contained two functions: hash(payload) — a plain unkeyed SHA-256 digest. The Hmac prefix in the class name was misleading; this function has no key parameter, so it could never have been an HMAC. hmacSHA256(key, data) — a properly keyed HMAC-SHA256. A reader who didn't engage with the function signature could in principle have assumed HmacSha256.hash(payload) was somehow keyed, but the absence of any key parameter made that …