http4k Path Traversal and Integrity Check Flaws

http4k's Digest authentication advertises the RFC 7616 auth-int quality-of-protection but never binds the request entity body into the digest, so an on-path attacker on a cleartext channel can rewrite the body of an already-authenticated, state-changing request while leaving the Authorization header valid. Affected is the org.http4k:http4k-security-digest module from 4.9.10.0 through 6.59.0.0, and only when an operator explicitly configures ServerFilters.DigestAuth with qop = listOf(Qop.AuthInt); the default Qop.Auth is not affected. The attack is unauthenticated - no credentials are needed - but requires a non-default QoP setting, no TLS, an active MITM foothold, and a body-omitting peer such as http4k's own DigestAuthReceiver, so a strictly RFC 7616-conformant client that hashes the body would simply fail to authenticate. A public PoC reference exists (a dependency-free digest-equivalence harness published with the advisory); it is not verified as working exploit code, and there is no confirmed active exploitation.

Path traversal in http4k’s ThymeleafTemplates Caching and HotReload wrappers allows remote unauthenticated attackers to read files outside baseTemplateDir when an application lets request-controlled data reach ViewModel.template() or its ::selector suffix. The issue affects http4k before 6.62.0.0-ee and is conditional on request-derived template selection; Pug4j is protected by commit 725f1b9697’s containment check, and the pinned Handlebars 4.5.5, FreeMarker and Pebble 4.1.2 engines are not affected. A verified component-level reproduction is published with the advisory, but there is no CISA KEV entry or confirmed exploitation of deployed applications, and impact is limited to disclosure of files readable by the server process; the assessed priority is this_week.