high · 7.5CVE-2026-69208Sep 15, 2026

CVE-2026-69208: http4s DigestAuth Nonce Map Unbounded Growth (DoS)

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A logic bug in http4s DigestAuth middleware causes the server's nonce map to grow forever, letting any unauthenticated attacker exhaust JVM heap memory by flooding DigestAuth-protected endpoints.

Packageorg.http4s:http4s-ember-server_2.12
Ecosystemmaven
Affected<= 0.23.34
Fixed in0.23.35
CVE-2026-69208: http4s DigestAuth Nonce Map Unbounded Growth (DoS)

The problem

The DigestAuth server middleware in http4s keeps a map of nonces to detect replays and expire stale tokens. Its cleanup routine contains an inverted comparison: it evicts fresh (still-valid) nonces and stops at the first stale one, so old nonces accumulate indefinitely.

Every unauthenticated request to a protected route creates a new map entry. An attacker with no credentials can drive continuous nonce creation, gradually consuming all available JVM heap memory until the process crashes with an OutOfMemoryError. The leak is persistent across requests and does not self-correct.

Proof of concept

A working proof-of-concept for CVE-2026-69208 in org.http4s:http4s-ember-server_2.12, with the exact payload below.

bash
# No credentials needed. Flood any DigestAuth-protected endpoint.
# Each 401 challenge mints a new nonce that is never evicted.

while true; do
  curl -s -o /dev/null http://target:8080/protected
done

The NonceKeeper cleanup loop compared nonce creation timestamps using the wrong operator, treating "time < threshold" as "time > threshold". This meant entries that had not yet expired were removed, while entries past their TTL were kept. Because every unauthenticated challenge call allocates a new nonce entry, and the broken eviction never removes old entries, the map grows without bound (CWE-401, CWE-400).

The patch in commit 8cfeda8472954d631dfbe5dc026463a27653e482 flips the comparison to correctly evict stale nonces, and also adds a hard cap of 1,000,000 nonces to absorb any burst between eviction cycles.

The fix

Upgrade to org.http4s:http4s-ember-server_2.12:0.23.35 (or 1.0.0-M47 on the v1 series). Both correct the eviction logic and impose a 1,000,000-entry hard cap. As a temporary workaround, rate-limit requests to DigestAuth-protected routes and restart the service periodically.

Reporter not attributed.

References: [1][2][3][4][5]

Related research