# An AI Agent Found 19 Redis Zero-Days — in About 90 Minutes

> Researchers say Kimi K3 agents chained a Redis streams double-free with a RedisBloom heap overflow into working authenticated RCE, with one exploit produced in 27 minutes. Redis shipped seven security releases in response. The claims are self-reported — but the patches are real.

Source: https://playciso.com/blog/kimi-k3-ai-agent-redis-zero-days · Published: 2026-07-24 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://cybersecuritynews.com/redis-server-0-day-exploit/

---

A researcher says AI agents built on Moonshot AI's **Kimi K3** model found **19 zero-day vulnerabilities in Redis** — one of the most widely deployed in-memory data stores on the internet — and turned at least two into working authenticated remote-code-execution exploits, with one exploit chain produced in roughly **27 minutes**. Redis shipped [seven security releases on July 23](https://thehackernews.com/2026/07/kimi-k3-agents-found-redis-zero-days.html) in response. The headline numbers are self-reported by the researcher, not independently verified — but the vulnerabilities and the patches are real and on the record. ## What Was Actually Found The research covered stock builds of Redis **6.2.22, 7.4.9, 8.6.4, and 8.8.0**, and chained two distinct memory-safety bugs into working exploits: - A streams "shared-NACK" double-free. A corrupted RDB object can make two different stream consumers reference the same pending-entry record. Removing both consumers frees that shared record twice — a classic double-free, but reached through Redis's own replication/persistence format rather than a malformed network packet. Reporting describes the resulting exploit as poisoning a database hash function so that a crafted GET call invokes system(), i.e., arbitrary command execution. - A heap overflow in the bundled RedisBloom TDigest module. The TDigest RDB loader allocates memory sized for one serialized value, then trusts a separate, attacker-controlled capacity field to decide how much data to actually load into that buffer — a classic allocate-one-size/trust-another-size mismatch that produces an out-of-bounds write, usable to leak Redis and libc memory addresses and defeat ASLR. Both bugs require authentication to reach — these are not unauthenticated, internet-scannable RCEs. But an enormous number of real-world Redis deployments run with weak or default auth, or are reachable from an already-compromised adjacent host, which is exactly the access level these exploits assume. ## The AI-Agent Claim Researcher Chaofan Shou said on X that Kimi K3 agents, given only a general instruction to look for memory-corruption issues, cloned the Redis source, fuzzed it, and debugged crashes with GDB — surfacing 19 zero-days in about 90 minutes of agent time, with the Redis 8.8.0 exploit specifically produced in 27 minutes. That is a genuinely fast turnaround for a vulnerability class (RDB deserialization double-frees, cross-field trust bugs) that normally takes a human researcher days of manual fuzzing and crash triage to isolate and weaponize. It's worth being precise about what's actually verified here. The vulnerabilities are real: Redis's own patch notes confirm the flaws and the fixes. The _count_ of 19, the _timing_ of 27 and 90 minutes, and the degree of agent autonomy are self-reported by the researcher and have not been independently reproduced or audited by a third party. As of this writing, neither flaw has a published NVD entry, and CISA's Known Exploited Vulnerabilities catalog lists neither — this is disclosed research, not (yet) evidence of in-the-wild exploitation. ## Patch Status Redis released fixes across both active branches on July 23, 2026: **6.2.23, 7.2.15, and 7.4.10** (streams double-free), and **8.2.8, 8.4.5, 8.6.5, and 8.8.1** (both issues, RedisBloom included). Notably, the May security releases that fixed an earlier related issue — including 6.2.22 and 7.4.9, versions users were specifically told to update to — still lacked the ownership guard that closes this particular double-free, meaning teams that dutifully patched in May are still exposed until this second round lands. ## What This Means for Security Teams - Patch Redis again, even if you patched it in May. The versions this affects include ones shipped as the fix for a prior, related bug. "We already updated" isn't a safe assumption without checking the specific patch version against Redis's July 23 advisories. - Authenticated-only is not low-risk by default. If Redis auth is weak, shared, or reachable from a compromised adjacent workload — common in practice — "requires authentication" collapses into "requires almost nothing." - AI-assisted vulnerability research changes your patch-window math. Whether or not the exact 27-minute figure holds up to scrutiny, the direction is real: agentic fuzzing-and-triage pipelines lower the cost of finding memory-safety bugs in widely deployed open-source infrastructure. The gap between "a bug exists" and "someone weaponizes it" is compressing on both the defender and attacker side. - Read self-reported security research the way you'd read a vendor benchmark. The underlying CVEs and patches here are independently confirmable through Redis's own release notes. The specific productivity claims about the AI agent are not yet independently verified — treat the two halves of the story with different levels of confidence. [Read the full story at Cybersecurity News →](https://cybersecuritynews.com/redis-server-0-day-exploit/) --- _PlayCISO's Threat Model and War Room studios run scenarios like this one — a widely deployed dependency, a patch that's easy to half-apply, and a decision about how fast your org actually re-patches. [See how PlayCISO handles patch-management and dependency-risk scenarios →](/soc)_