GHSA-C7JM-38GQ-H67H: Authentication Bypass via Replay Attack in http4k-security-digest due to Insecure Default Nonce Verifier

The http4k framework is an HTTP toolkit written in Kotlin. Within the http4k-security-digest module, the ServerFilters.DigestAuth filter and DigestAuthProvider class provide HTTP Digest Access Authentication capabilities, designed to secure server-side routes.

HTTP Digest Authentication (defined in RFC 2617 and RFC 7616) relies on a challenge-response protocol. It calculates MD5 or SHA-256 digests over a collection of credentials, target URIs, and cryptographically generated server values known as nonces. The protocol requires the server to verify the validity, integrity, and freshness of these nonces to prevent attackers from reusing legitimate client-submitted headers.

In vulnerable versions of http4k-security-digest, the default implementation of the nonceVerifier was hardcoded to accept any incoming string as valid. This configuration-level oversight exposes protected endpoints to capture-replay vulnerabilities, undermining the core security guarantees of the digest authentication scheme.

The root cause of this vulnerability lies in the improper verification of cryptographic signatures and session freshness, classified under CWE-347 and CWE-294. In HTTP Digest Authentication, the nonce acts as a single-use token that prevents attackers from capturing a user's cryptographic response and using it in future requests.

To ensure proper security, a NonceVerifier must perform multiple checks: it must confirm that the nonce was generated by the server, verify that the timestamp embedded inside the nonce is within a defined time-to-live window, and ensure the nonce has not been consumed previously. If the client request incorporates quality-of-protection (qop) options, the server must also track the nonce counter (nc) to prevent multi-use replays.

Prior to version 6.48.0.0 of http4k, the default signature of DigestAuth assigned the lambda { true } to the nonceVerifier parameter. Consequently, the server skipped all state, freshness, and signature verification checks on the client-supplied nonce. Any string provided in the nonce field of the Authorization header was accepted unconditionally, allowing the cryptographic hash evaluation to succeed for outdated, stolen, or entirely fabricated nonces.

In the vulnerable implementation of the http4k-security-digest module, the ServerFilters.DigestAuth filter was configured with insecure defaults. The snippet below highlights the vulnerable parameter declarations in serverFilterExtensions.kt:

// VULNERABLE CODE PATH
fun ServerFilters.DigestAuth(
    realm: String,
    passwordLookup: (String) -> String?,
    qop: List<Qop> = listOf(Qop.Auth),
    digestMode: DigestMode = DigestMode.Standard,
    nonceGenerator: NonceGenerator = SECURE_NONCE,
    nonceVerifier: NonceVerifier = { true }, // <-- VULNERABILITY: Bypasses validation
    algorithm: String = "MD5",
    usernameKey: RequestContextLens<String>? = null,
): Filter

The fix implemented in commit 4f904b4692c104c2a20ae8dbf89bd86a2211ff67 resolved this by removing the default values for both nonceGenerator and nonceVerifier, making them mandatory parameters that must be supplied by the developer:

// PATCHED CODE PATH
fun ServerFilters.DigestAuth(
    realm: String,
    passwordLookup: (String) -> String?,
    qop: List<Qop> = listOf(Auth),
    digestMode: DigestMode = Standard,
    nonceGenerator: NonceGenerator,  // <-- Forced parameter declaration
    nonceVerifier: NonceVerifier,    // <-- Forced parameter declaration
    algorithm: String = "MD5",
    usernameKey: RequestLens<String>? = null,
): Filter

Similarly, the default value in DigestAuthProvider.kt was removed to ensure compile-time safety. This breaking API change prevents developers from accidentally deploying authentication filters with an inactive verification loop.

To exploit this vulnerability, an attacker must acquire a valid Authorization header from a legitimate client request. This is achieved via local network sniffing, machine-in-the-middle positioning on unencrypted HTTP channels, log leakages, or reverse proxy inspection.

Once the attacker captures the payload, they can perform the replay attack. Because the server does not enforce nonce uniqueness or age verification, the captured header remains valid indefinitely, provided the client's password remains unchanged.

No complex custom client software is required. An attacker can retransmit the exact header via standard utilities such as cURL or Postman to gain access to the target endpoint under the identity of the compromised user.

The impact of this vulnerability is the complete breakdown of the authentication boundary for endpoints using default digest authentication settings. Attackers can hijack active sessions and perform unauthorized state-changing operations or retrieve confidential data.

Upgrading the library fixes the default behaviors, but developers face a residual risk of self-reintroduction. When upgrading to version 6.48.0.0 or later, compilation errors will occur on prior implementations. To bypass these errors quickly, developers may be tempted to explicitly set nonceVerifier = { true }. This action reintroduces the vulnerability.

Additionally, if developers adopt a stateless, signed-nonce design without recording consumed tokens, attackers can still replay authentication requests within the short time window permitted by the signature's expiration claim. Absolute protection requires recording stateful markers (e.g., in a shared cache like Redis) to block duplicate nonce submissions entirely.