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

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 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 →

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 →