CVE-2026-69208: Memory Leak and Denial of Service in http4s DigestAuth Middleware

The vulnerability affects the http4s Scala library, specifically within its server-side DigestAuth middleware implemented in components such as DigestAuth.scala, NonceKeeper.scala, and NonceKeeperF.scala. The DigestAuth middleware provides HTTP Digest Access Authentication, protecting defined routes by validating request credentials against unique, short-lived cryptographic tokens called nonces.

To prevent reply attacks and control session validity, the server maintains nonces inside an internal, insertion-ordered LinkedHashMap. The middleware uses this map to keep track of valid tokens and is designed to periodically evict expired tokens that exceed a configured lifetime (staleTimeout). Under normal operations, this cache management system ensures that memory consumption remains bounded and stable even under heavy user activity.

However, a logic error in the eviction subroutine reverses the stale-nonce check condition. The application incorrectly retains expired nonces indefinitely and deletes active sessions instead. Because this middleware operates on unauthenticated endpoints to challenge incoming requests, any remote user can trigger the generation of new cached nonces, presenting a major remote attack surface.

The root cause of this vulnerability lies in a logic inversion bug within the eviction routing of both the legacy NonceKeeper class and the effect-based NonceKeeperF class. Under the HTTP Digest Authentication specification, nonces are tracked chronologically to ensure older elements are processed first. The eviction loop utilizes an iterator over the underlying map, walking from the oldest entry to the newest.

In the vulnerable codebase, the age of each nonce is evaluated against the staleTimeout parameter using the following comparison: staleTimeout > age (calculated as current time minus creation time). When this inequality evaluates to true, the elapsed time is less than the threshold, indicating that the token is still active and valid. Because of the logic flaw, the code incorrectly identifies active nonces as candidates for deletion and removes them via it.remove().

Conversely, when the loop encounters the first truly expired nonce, the age exceeds the timeout, making the statement staleTimeout > age evaluate to false. At this point, the conditional check fails and the recursive eviction subroutine halts immediately. Since the collection is organized sequentially by insertion time, the presence of a single expired nonce at the head of the collection blocks all subsequent stale nonces from being evaluated, leading to a permanent memory leak.

Analyzing the implementation details highlights the exact line-level differences before and after the remediation. In the vulnerable version of NonceKeeper.scala, the tail-recursive clean-up loop was written as follows:

val it = nonces.values().iterator()
@tailrec
def dropStale(): Unit = {
  // BUG: staleTimeout > age evaluates to true only for active, fresh nonces
  if (it.hasNext && staleTimeout > d - it.next().created.getTime) {
    it.remove() // Incorrectly deletes the valid nonce
    dropStale() // Recursively continues
  }
  // Loop exits on the first expired nonce, leaving it and all newer entries in memory
}

In the patched version of the file, the maintainers corrected the conditional operator to verify that the elapsed age is greater than or equal to the timeout threshold:

val it = nonces.values().iterator()
@tailrec
def dropStale(): Unit = {
  // FIX: Verify that the nonce has actually aged past the stale timeout limit
  if (it.hasNext && d - it.next().created.getTime >= staleTimeout) {
    it.remove() // Safely expels the expired nonce
    dropStale() // Continues to clean up subsequent expired nonces
  }
  // Loop correctly terminates once it encounters the first valid (fresh) nonce
}

Additionally, to safeguard the application from extreme, rapid volume surges that could overwhelm the background thread's clean-up frequency, the maintainers implemented a hard cap on the size of the underlying LinkedHashMap by overriding the removeEldestEntry method in NonceKeeperF.scala. This ensures that the map self-truncates if it reaches the maximum capacity defined by the maxNonces parameter.

Exploiting this flaw does not require authentication or specific request structures. An attacker targets any endpoint protected by the DigestAuth middleware and executes the following programmatic steps:

1. The attacker issues an initial HTTP request to the protected path without an Authorization header.

2. The server responds with an HTTP 401 Unauthorized status and includes a WWW-Authenticate header containing a newly generated, unique nonce value.

3. The server allocates memory for this new nonce and stores it in the LinkedHashMap cache.

4. The attacker ignores the challenge and repeats step 1 at a high frequency. Because the eviction subroutine is broken, none of the generated nonces are ever discarded from the server's memory.

This sequence can be automated with simple HTTP flooding utilities. Over time, the accumulated footprint of the NonceF metadata blocks, hash map entries, and string keys exhausts the allocated Java Virtual Machine (JVM) heap space, resulting in severe performance degradation and an eventual crash.

The primary impact of CVE-2026-69208 is complete denial of service. Because the application crashes due to a heap exhaustion event (java.lang.OutOfMemoryError), the entire service becomes unresponsive, affecting all other endpoints running on the same JVM instance.

While the patch remediates the logic inversion and introduces a hard size limit (maxNonces), security teams must evaluate potential residual risks. The default value for maxNonces is set to 1,000,000. In resource-constrained environments (such as Kubernetes pods running with less than 1GB of RAM), storing up to one million complex nonce objects, dates, and corresponding reference metadata inside the JVM heap may still consume sufficient memory to trigger an OutOfMemoryError before the threshold limit is reached.

Furthermore, legacy methods retained for binary compatibility preserve the old signatures, which default the maxNonces parameter to Int.MaxValue. If downstream applications call these deprecated interfaces directly, they will remain unbounded, relying exclusively on the temporal clean-up loop.

To fully resolve the vulnerability, organizations should upgrade their http4s dependencies to the patched releases.

Applications tracking the 0.23.x release branch must be updated to version 0.23.35 or later. Applications tracking the 1.0.0 milestone branch must be upgraded to 1.0.0-M47 or later.

If upgrading is not immediately possible, security teams can implement several tactical mitigations:

• Configure upstream Web Application Firewalls (WAF) or reverse proxies to rate-limit unauthenticated requests targeting protected routes, preventing rapid nonce generation.

• Set up explicit alerts on JVM memory usage, tracking rapid growth of NonceF and LinkedHashMap object allocations.

• Avoid calling deprecated middleware builders that default the maximum nonce count to Int.MaxValue, and instead transition to initialization patterns that allow setting a conservative custom limit for maximum cached nonces.