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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact An issue in DigestAuthProvider.verify: The uri parameter in the client's Authorization: Digest … response was not checked against the actual request URL. A captured Digest authentication response could be replayed against any other URL served by the same realm, breaking the per-request-URL binding the Digest scheme assumes. Who is affected: any application using http4k-security-digest for HTTP Digest authentication. The bug has been present since DigestAuthProvider was introduced (commit 8a52b615b1, 2021). Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | 6.50.0.0 | Community | | v5.x (LTS) | 5.42.0.0 | Enterprise — contact enterprise@http4k.org (if Digest auth is present in your v5.x line) | | v4.x (LTS) | 4.51.0.0 | Enterprise — contact enterprise@http4k.org (if Digest auth is present in your v4.x line) | The fix: - Rejects credentials whose uri parameter does not match the request URL. Workarounds For deployments that cannot upgrade…
Recommended action: Upgrade to 6.50.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 An issue in DigestAuthProvider.verify: Algorithm silently forced to MD5. The configured algorithm parameter was ignored — every verification used MD5 regardless of configuration. Deployments believing they were running SHA-256 Digest auth were silently inheriting MD5's collision weaknesses, including documented attack paths against Digest schemes that rely on the hash being collision-resistant. Who is affected: any application using http4k-security-digest for HTTP Digest authentication. The bug has been present since DigestAuthProvider was introduced (commit 8a52b615b1, 2021). Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | 6.50.0.0 | Community | | v5.x (LTS) | 5.42.0.0 | Enterprise — contact enterprise@http4k.org (if Digest auth is present in your v5.x line) | | v4.x (LTS) | 4.51.0.0 | Enterprise — contact enterprise@http4k.org (if Digest auth is present in your v4.x line) | The fix: - Hashes with the configured algorithm instead of…
Recommended action: Upgrade to 6.50.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 ServerFilters.DigestAuth and the underlying DigestAuthProvider both defaulted their nonceVerifier parameter to { true } — i.e. every nonce was accepted regardless of value, age, or prior use. Any deployment using the default configuration had no replay protection on Digest authentication; a captured Authorization: Digest … response could be replayed indefinitely against the same protected resource. The nonce-verification mechanism in Digest auth is the primary anti-replay control — without it, Digest reduces to a credential bound only to a stale nonce string. Who is affected: any application using ServerFilters.DigestAuth or DigestAuthProvider with the default nonceVerifier. The broken default has been present since DigestAuthProvider was introduced (2021). Exploitation requires the attacker to first capture a valid Digest response (network observation, log access, etc.) — non-trivial in modern TLS deployments but not impossible. Anyone running Digest auth with default config…
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.