Researchers using Moonshot AI’s Kimi K3 model as an autonomous bug-hunting agent say it surfaced multiple authenticated remote-code-execution paths in Redis on July 23-24, hitting stock builds across the 6.2, 7.2, 7.4, 8.2, 8.4, 8.6, and 8.8 branches. Redis has already shipped fixes; no CVE identifiers had been assigned as of this writing, and no in-the-wild exploitation has been reported, but the underlying bug classes are now public and a working exploit reportedly took as little as 27 minutes to generate.
What’s broken
Two distinct, independently exploitable issues are involved.
Stream shared-NACK double-free. Redis streams use consumer groups to track which client is responsible for delivering a given entry; pending entries are tracked via NACK (not-acknowledged) structures that can be shared across consumers in the same group. The reported flaw lets an authenticated client drive the shared-NACK bookkeeping into a state where the same heap chunk is freed twice. A double-free is a reliable primitive for heap grooming — an attacker can reallocate the freed chunk with attacker-controlled data before the second free lands, turning a memory-safety bug into code execution.
RedisBloom TDigest heap overflow. RedisBloom, the probabilistic-data-structures module bundled with modern Redis Stack builds, includes a TDigest implementation for streaming percentile estimation. Its loader allocates a buffer sized from one field in a serialized TDigest payload but then trusts a separate, attacker-controlled “capacity” field when copying data into that buffer during deserialization — a classic size-confusion bug that produces an out-of-bounds heap write (CWE-787). Any code path that loads or restores a TDigest structure from untrusted input — replication, RESTORE, RDB/AOF loading from an attacker-influenced file, or a module command that accepts serialized TDigest data — is a candidate trigger.
Both bugs require an authenticated session against the Redis instance; neither is a pre-auth remote hole. But Redis deployments are routinely reachable from application tiers with weak or shared credentials, and the two bug classes are unrelated enough that a single hardening pass won’t catch both.
Discovery process
According to researcher Chaofan Shou, Kimi K3 agents running autonomously found on the order of 19 Redis zero-day-class bugs in roughly 90 minutes of agent time during one run, and a separate run produced a working RCE exploit for Redis 8.8.0 in about 27 minutes. Those figures are self-reported by the researchers involved and haven’t been independently reproduced end-to-end, but the underlying bugs and patches are real and confirmed by Redis’s own release notes. This is the second AI-discovered Redis memory-corruption bug this summer, after June’s CVE-2026-23479 use-after-free in the blocking-client path — a reminder that automated source-review agents are now finding real, exploitable bugs in widely deployed C codebases faster than manual audit cycles typically do.
Impact
Redis is one of the most widely deployed in-memory data stores on the internet — caching layers, session stores, message queues, and leaderboard/analytics workloads all commonly run it, frequently with RedisBloom or full Redis Stack enabled by default in managed offerings. An authenticated RCE against the Redis process typically means code execution as the redis service user, with a direct path to lateral movement if the instance sits on an internal network with reused credentials, or to full compromise if Redis is running with elevated privileges or alongside sensitive local files.
Anyone running self-managed Redis with RedisBloom, or Redis Stack images built before this week, should treat this as exposure until confirmed patched — check your image or package version against the fixed releases below rather than assuming a managed provider has already rolled it out.
Mitigation
- Upgrade to a fixed release: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, or 8.8.1, matching your current branch.
- If you can’t patch immediately, require strong, unique Redis AUTH credentials and restrict network reachability to the instance with firewall rules or security groups — neither bug is exploitable pre-auth.
- Audit whether RedisBloom/TDigest is actually in use; if not, disable the module to remove that attack surface entirely.
- Review stream consumer-group usage for anomalous NACK claim/reclaim patterns as a detection signal while you roll out patches.
- If you operate a managed Redis service (cloud provider or internal platform team), confirm the underlying engine version has been bumped — don’t assume the platform patched silently.