Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 6.49.0.0 or 5.42.0.0 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 directly with cookies for more than one origin or scheme. Single-origin uses are unaffected. Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | 6.48.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 introduces DefaultCookieStorage (RFC 6265 compliant) as the drop-in default; BasicCookieStorage is renamed InsecureCookieStorage and remains…
Recommended action: Upgrade to 6.48.0.0, 5.42.0.0 or 4.51.0.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 misuse unlikely in practice. Who is affected: any downstream caller who read the class name and used HmacSha256.hash as a message authentication code without noticing it takes no key. Verified at v6.47.2.0: zero internal misuse in http4k itself. Both production usages of HmacSha256.hash (AWS SigV4 canonical-request hashing in AwsSignatureV4Signer.kt and x-amz-content-sha256 in awsExtensions.kt) are AWS-spec-correct uses of plain SHA-256; every keyed hmacSHA256(key, data) call passes a real key. The advisory exists so any downstream…
Recommended action: Upgrade to 6.49.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. If, however, reverseProxy() was deployed as a public-facing inbound HTTP handler — which the function technically supports but is not the documented intent — an external attacker could send Host: admin.evil.com and reach a vhost configured as admin, bypassing routing-based authorization. The Contains matcher's docstring explicitly documented this loose behaviour, but because Contains was the default, callers who never read the matcher docs would still get the loose behaviour. Who is affected: only deployments using…
Recommended action: Upgrade to 6.49.0.0, 5.42.0.0 or 4.51.0.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.