http4k: `ServerFilters.DigestAuth` / `DigestAuthProvider` defaulted to an always-true nonce verifier, disabling replay protection in default deployments

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 should treat upgrade as urgent.

Patches

Line	Fixed in	Edition
v6.x (Community)	6.48.0.0	Community
v5.x (LTS)	5.42.0.0	Enterprise — contact [email protected] (if Digest auth is present in your v5.x line)
v4.x (LTS)	4.51.0.0	Enterprise — contact [email protected] (if Digest auth is present in your v4.x line)

The fix ([Break]) removes the default value for nonceVerifier from both ServerFilters.DigestAuth and DigestAuthProvider. Callers must now supply a real verifier explicitly — the broken default cannot be silently inherited.

Workarounds

For deployments that cannot upgrade immediately: explicitly supply a that tracks issued nonces, enforces a TTL, and rejects re-use. Do not rely on the default.