AIKIDO-2026-989333

moka is vulnerable to Uncontrolled Resource Consumption

Uncontrolled Resource Consumption Pre-CVE Published Aug 12, 2026

Medium Risk

This Affects:

moka

0.12.0 - 0.12.15

Fixed in 0.12.16

Are you affected? Scan for Free

TL;DR

Moka's sync::Cache, sync::SegmentedCache, and future::Cache process buffered write operations while running maintenance tasks. A race between applying a stale upsert write-recording for a key and concurrently removing that same key from the internal concurrent hash table can leave an orphaned node at the front of the eviction queue. When the cache is configured with the non-default LRU eviction policy (EvictionPolicy::lru()), that orphan permanently stalls eviction: nothing is evicted again and the cache grows without bound past its configured max_capacity, eventually exhausting memory. With the default TinyLFU eviction policy the same race is milder — each occurrence permanently leaks one phantom capacity slot, so entry_count/weighted_size over-report and usable capacity shrinks by one entry per occurrence. The fix retires entries atomically with their hash-table removal and skips retired entries during buffered policy operations and victim scans.

Who does this affect?

You are affected if you use a version in the vulnerable range and your application concurrently inserts/updates and removes (or evicts) the same cache keys under load. The severe impact — permanently stalled eviction and unbounded memory growth past max_capacity ending in OOM — only occurs when the cache is configured with the non-default LRU eviction policy (EvictionPolicy::lru()). With the default TinyLFU eviction policy the effect is limited to a gradual, per-occurrence leak of usable capacity (over-reported entry_count/weighted_size). Workloads that cache values keyed on user-controlled or externally influenced inputs that are frequently reused are the most likely to hit the race.