http4k EUVD-2026-115006

Requires all of: (1) the non-default configuration ServerFilters.DigestAuth(..., qop = listOf(Qop.AuthInt), ...) - the default Qop.Auth is not exploitable for this issue; (2) a non-TLS (cleartext) transport, since TLS independently protects the body; (3) an active man-in-the-middle position able to read and rewrite in-flight requests; and (4) interoperability only with a body-omitting peer such as http4k's own DigestAuthReceiver (a strictly RFC 7616-conformant client that hashes the body would fail to authenticate). No credentials are needed and no victim action beyond sending a normal authenticated request is required. These limiting factors - non-default QoP, cleartext channel, and MITM foothold - substantially constrain realistic exploitation despite the unauthenticated (PR:N) nature of the attack.

Signals point to a genuine but condition-bound integrity flaw rather than a broad emergency. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N) scores 8.2 and correctly reflects that no credentials are needed (PR:N) but that success depends on specialized conditions: AC:H and AT:P capture the need for an active on-path position on a non-TLS channel plus a non-default QoP configuration. KEV status is NO (not CISA-listed) and no EPSS score was provided, so there is no evidence of widespread or automated exploitation; the vuln.today Decision label is 'this_week', consistent with prompt remediation but short of act_now/emergency. A public PoC reference exists in the GHSA advisory - a dependency-free harness that recomputes the auth-int pre-image and shows identical digests for two different bodies - but it demonstrates the digest collision, not a turnkey network MITM exploit, so PoC availability must not be conflated with active exploitation. Note two data caveats: the input Tags label this 'Information Disclosure', which conflicts with the vector (VC:N, VI:H) - this is a message-integrity/tampering flaw, not confidentiality loss; and the fixed version shows a discrepancy (CVE metadata says fixed in 6.60.0.0, while the GHSA source snapshot examined at 6.59.0.0 reported 'not fixed' because 6.60.0.0 was not yet published). Net: a real, high-integrity-impact issue for the specific deployments that enabled auth-int over cleartext, but the non-default configuration and MITM prerequisite meaningfully bound real-world exposure.

An operator enabled http4k Digest auth with qop=auth-int over a non-TLS channel, trusting auth-int to protect the request body. An on-path attacker with no knowledge of the credentials observes a victim's authenticated state-changing POST (e.g. amount=10&to=alice) and rewrites the body to amount=999999&to=attacker while leaving the method, URI, nonce and Authorization header untouched; the server recomputes a body-independent digest, accepts the tampered request, and executes it as the victim. A public PoC harness in the advisory demonstrates that both bodies produce an identical auth-int digest.