Http4K
Monthly
Replay of captured Digest authentication credentials is possible in the http4k http4k-security-digest module (org.http4k:http4k-security-digest) because ServerFilters.DigestAuth and the underlying DigestAuthProvider default their nonceVerifier parameter to { true }, accepting every nonce regardless of value, age, or prior use. Any application that uses these components with the default configuration and exposes a protected resource has no replay protection: an attacker who obtains a valid 'Authorization: Digest' header - for example through network observation or reading logs that record the header - can replay that response indefinitely against the same resource, yielding credential-equivalent access and information disclosure rather than modification of data. The weakness has been present since DigestAuthProvider was introduced in 2021; the CVSS 4.0 score is 8.2 (8.2 with AT:P reflecting the capture prerequisite), and the independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, treating it as a real but conditionally gated authentication weakness rather than a mass-exploitable critical. There is no public exploit identified at time of analysis, and vendor-released patches exist in 6.48.0.0, 5.42.0.0, and 4.51.0.0.
Cookie scoping bypass in the http4k client-side cookie jar (Maven org.http4k:http4k-core) causes cookies stored by BasicCookieStorage to be replayed to origins and schemes they were never scoped to, potentially exposing session cookies or other sensitive values. Only applications that reuse a single storage instance across more than one origin or scheme are affected; per-origin instances are explicitly unaffected, and no public exploit identified at time of analysis. The vendor rates this 8.3 (CVSS 4.0) while an independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, reflecting a conditional client-side confidentiality flaw that additionally requires an attacker-controlled or attacker-observable second destination before leaked cookies can be captured, making it moderate rather than high-urgency. Fixes ship in 6.48.0.0, 5.42.0.0, and 4.51.0.0; authentication is not required to trigger the flawed behavior (CVSS PR:N), but exploitation depends on the developer's multi-origin storage configuration rather than on attacker-supplied input reaching a server.
Host-header routing bypass in http4k (Maven artifact org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 lets remote, unauthenticated attackers reach a virtual host they should not be authorized for by supplying a Host header that merely contains a configured vhost name - for example Host: admin.evil.com against a vhost configured as "admin" - because reverseProxy() and reverseProxyRouting() default to a substring (Contains) matcher rather than an exact match. Exploitation is tightly scoped: it requires the functions to be deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, where that routing is what enforces authorization; the documented outbound-dispatch and test-time fake-backend uses set the Host value from the calling application and are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is a genuine but narrow authorization-bypass rather than a high-severity emergency; vendor patches are available in 6.49.0.0 (Community 6.x), 5.42.0.0 and 4.51.0.0 (Enterprise LTS lines).
Replay of captured Digest authentication credentials is possible in the http4k http4k-security-digest module (org.http4k:http4k-security-digest) because ServerFilters.DigestAuth and the underlying DigestAuthProvider default their nonceVerifier parameter to { true }, accepting every nonce regardless of value, age, or prior use. Any application that uses these components with the default configuration and exposes a protected resource has no replay protection: an attacker who obtains a valid 'Authorization: Digest' header - for example through network observation or reading logs that record the header - can replay that response indefinitely against the same resource, yielding credential-equivalent access and information disclosure rather than modification of data. The weakness has been present since DigestAuthProvider was introduced in 2021; the CVSS 4.0 score is 8.2 (8.2 with AT:P reflecting the capture prerequisite), and the independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, treating it as a real but conditionally gated authentication weakness rather than a mass-exploitable critical. There is no public exploit identified at time of analysis, and vendor-released patches exist in 6.48.0.0, 5.42.0.0, and 4.51.0.0.
Cookie scoping bypass in the http4k client-side cookie jar (Maven org.http4k:http4k-core) causes cookies stored by BasicCookieStorage to be replayed to origins and schemes they were never scoped to, potentially exposing session cookies or other sensitive values. Only applications that reuse a single storage instance across more than one origin or scheme are affected; per-origin instances are explicitly unaffected, and no public exploit identified at time of analysis. The vendor rates this 8.3 (CVSS 4.0) while an independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, reflecting a conditional client-side confidentiality flaw that additionally requires an attacker-controlled or attacker-observable second destination before leaked cookies can be captured, making it moderate rather than high-urgency. Fixes ship in 6.48.0.0, 5.42.0.0, and 4.51.0.0; authentication is not required to trigger the flawed behavior (CVSS PR:N), but exploitation depends on the developer's multi-origin storage configuration rather than on attacker-supplied input reaching a server.
Host-header routing bypass in http4k (Maven artifact org.http4k:http4k-core) before 6.49.0.0, 5.42.0.0 and 4.51.0.0 lets remote, unauthenticated attackers reach a virtual host they should not be authorized for by supplying a Host header that merely contains a configured vhost name - for example Host: admin.evil.com against a vhost configured as "admin" - because reverseProxy() and reverseProxyRouting() default to a substring (Contains) matcher rather than an exact match. Exploitation is tightly scoped: it requires the functions to be deployed as a public-facing inbound HTTP handler with two or more configured virtual hosts, where that routing is what enforces authorization; the documented outbound-dispatch and test-time fake-backend uses set the Host value from the calling application and are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the issue is a genuine but narrow authorization-bypass rather than a high-severity emergency; vendor patches are available in 6.49.0.0 (Community 6.x), 5.42.0.0 and 4.51.0.0 (Enterprise LTS lines).