Kimi K3 agents found Redis zero-days — here's what Redis actually patched, and what's still just a claim
A researcher says Kimi K3 agents found 19 Redis zero-days in ~90 minutes and built an RCE exploit for Redis 8.8.0 in 27. Redis shipped seven security releases on July 23, 2026 across every supported branch. The patches are verified; the counts and timings are not. Here's the split, and the versions you need to be on.
Security researcher Chaofan Shou says agents running on Kimi K3 found memory-corruption bugs in Redis and produced a working remote-code-execution proof of concept. Redis shipped patches days later. Both halves of that sentence are true — but only one half is independently verifiable, and the difference matters if you’re deciding what to tell your team.
Key facts:
- Redis published seven security releases on July 23, 2026, across every supported branch. (Source: redis/redis releases, verified 2026-07-27)
- Patched versions: 8.8.1, 8.6.5, 8.4.5, 8.2.8, 7.4.10, 7.2.15, 6.2.23.
- Two bug classes: a Streams shared-NACK use-after-free, and a RedisBloom/TDigest out-of-bounds write in the RDB loader.
- Both paths require the
RESTOREcommand. The Streams chain also needsEVALandXGROUP; the 8.8.0 chain needs the bundled RedisBloom module. - The claim of “19 zero-days in ~90 minutes” is self-reported and has not been confirmed by Redis maintainers or Moonshot AI. (Source: The Hacker News, 2026-07-24)
What’s verified
The patches are real and you can read them yourself. Redis 8.8.1’s release notes carry a single security entry pointing at RedisBloom PR #1044.
The fix itself is a hardening pass on the RDB restore path — exactly the shape you’d expect for a RESTORE-triggered memory bug.
What’s not verified
The headline numbers are the researcher’s own. Redis’s release notes carry no CVE or CVSS score for the new bug classes, and as of July 24 there was no separate NVD record for the shared-NACK or TDigest findings, nor a CISA Known Exploited Vulnerabilities listing. CVE-2026-25589 is associated with RedisBloom memory corruption during RESTORE, but the mapping to the specific claims is not clean. No in-the-wild exploitation had been reported as of July 24, 2026.
So: the bugs exist and are fixed. How many there were, how long an agent took, and how autonomously it worked are all unconfirmed.
What this means if you’re building with Kimi K3
Two separate takeaways, and it’s worth not blurring them.
Operationally, patch. If you run Redis and expose RESTORE to anything less than fully trusted, move to a patched branch now. Both chains are authenticated — that lowers the severity considerably, but “authenticated” includes any app-tier credential an attacker already has. Restricting RESTORE, EVAL and XGROUP via ACLs is the cheap mitigation if you can’t upgrade today.
Strategically, note what tier of model did this. The interesting part isn’t the exploit — it’s that an open-weight-adjacent frontier model was pointed at a C codebase with a short prompt and came back with crash reproductions. Fuzzing, GDB triage and patch-diffing are becoming things you can put in a loop rather than staff. If you’re already using K3 for coding, the same harness pattern applies to your own dependency audit — and to anyone auditing you. Our Kimi K3 guide covers the setup; the GLM-5.2 Semgrep cyber-benchmark results are the closest thing to a controlled measurement of this capability class.
Treat single-researcher agent claims the way you’d treat a self-reported benchmark: useful signal, not a number to quote.
Sources
- Redis releases — 8.8.1 and the July 23 security batch (Redis, primary source)
- RedisBloom PR #1044 — Harden RDB loading (RedisBloom, primary source)
- Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say (The Hacker News, 2026-07-24)
- Kimi K3: Chinese AI finds several zero-day vulnerabilities in Redis database (heise online)
Source: The Hacker News