http4k Security Digest EUVD-2026-87852

Applies only to applications that use ServerFilters.DigestAuth or DigestAuthProvider from org.http4k:http4k-security-digest AND rely on the default nonceVerifier (the { true } always-accept default present since the module's 2021 introduction); applications that already pass an explicit nonce-tracking verifier are unaffected. Exploitation further requires the attacker to first obtain a valid 'Authorization: Digest' header - via network observation of cleartext/decrypted traffic or access to logs that record the header - which limits realistic exploitation to attackers with a traffic-interception vantage point or log access. Deployments serving Digest auth strictly over end-to-end TLS with no header logging substantially raise the difficulty of the required capture step.

This is a real but conditionally-gated authentication weakness rather than a mass-exploitable critical. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) rates it 8.2, but the single most important signal is AT:P (Attack Requirements: Present) - exploitation is impossible until the attacker first captures a valid 'Authorization: Digest' header, which the vendor itself concedes is 'non-trivial in modern TLS deployments but not impossible.' PR:N is accurate: the replayer never needs their own credentials, they reuse a captured one. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or automatable exploitation - consistent with a flaw that requires a prerequisite man-in-the-middle position or log/traffic access. SSVC-style reading: exploitation status = none observed, automatable = no (the capture step is opportunistic and environment-specific), technical impact = partial (grants access to one protected resource, no code execution). The vendor scores confidentiality VC:H with VI:N/VA:N; I largely agree the impact is bounded to unauthorized access of the Digest-protected resource. Net: prioritize for teams that actually deploy http4k Digest auth over cleartext or with accessible logs, but it does not warrant emergency patching for the general population given the capture precondition and absence of KEV/EPSS/POC evidence.

An attacker positioned to observe network traffic to an http4k service that terminates TLS upstream (or one exposing Digest headers in application/proxy logs) captures a legitimate user's 'Authorization: Digest' response. Because the default nonceVerifier is { true }, the server accepts that same nonce forever, so the attacker replays the captured header to authenticate as that user against the protected resource indefinitely. No public exploit code was identified at time of analysis; exploitation hinges on the attacker's ability to capture a valid Digest response.