Redis, one of the world’s most widely deployed in-memory databases, shipped seven emergency security releases on July 23, 2026, after researchers published working remote code execution exploits against four separate stock versions. What makes this disclosure different from a typical patch cycle is who — or what — found the flaws: an AI agent called Kimi K3, working almost entirely on its own.
Security researcher Chaofan Shou, publishing under the alias Bera Buddies, says he coordinated 32 specialized Kimi K3 agents that cloned Redis’s source code, built fuzzers, instrumented the software, debugged crashes, and produced a working authenticated exploit — in 27 minutes. In a separate post, he claims the same workflow surfaced 19 zero-days in the newest Redis release in roughly 90 minutes.
What Vulnerabilities Did the AI Actually Find?
The Kimi K3 Redis vulnerability research uncovered two distinct bug classes, both requiring an authenticated connection and Redis’s RESTORE command to trigger:
- Streams shared-NACK double-free: A corrupted RDB object can trick two consumers in a Redis Streams consumer group into pointing at the same pending-entry record. Removing both consumers frees the same memory twice, and the published exploit script turns that double-free into arbitrary memory access, ultimately calling system() on the server.
- RedisBloom TDigest heap overflow: The RedisBloom module’s TDigest data loader allocated memory based on one value in a saved file but trusted a separate, attacker-controlled field to decide how much data to write into it — a classic recipe for an out-of-bounds write that can leak memory addresses and again lead to code execution.
Notably, the Streams issue traces back to an incomplete fix. Redis had already patched a related flaw, tracked as CVE-2026-25589, but a source-code review by The Hacker News found that the officially released Redis 8.6.4 was still missing the duplicate-ownership check the fix was supposed to add — the guard only actually appeared in the follow-up 8.6.5 release on July 23. Redis’s May releases also addressed a related RedisBloom memory corruption issue tracked as CVE-2026-25243, though Redis’s July release notes list no separate CVE or CVSS score for either newly disclosed bug class.
Which Redis Versions Need Patching
| Affected Version | Issue | Fixed In |
|---|---|---|
| 6.2.22 | Streams shared-NACK | 6.2.23 |
| 7.4.9 | Streams shared-NACK | 7.2.15 / 7.4.10 |
| 8.6.4 | Streams + RedisBloom + TDigest | 8.2.8 / 8.4.5 / 8.6.5 |
| 8.8.0 | RedisBloom + TDigest loaders | 8.8.1 |
As of July 24, 2026, neither Redis’s official release notes nor the public proof-of-concept repositories reported any evidence of in-the-wild exploitation, and searches of the National Vulnerability Database and CISA’s Known Exploited Vulnerabilities catalog turned up no entries for either new bug class — this appears to be responsible disclosure, not an active attack.
Can AI Really Find Zero-Day Vulnerabilities on Its Own?
Separating what’s confirmed from what’s still just a claim matters here, so here’s the breakdown:
| Claim | Status |
|---|---|
| Redis has these memory-corruption flaws | Confirmed — Redis shipped patches for them |
| A working exploit was built | Confirmed — public PoC code exists on GitHub |
| 32 AI agents did this in 27 minutes | Self-reported by the researcher, unverified |
| 19 zero-days found in 90 minutes | Self-reported claim, not independently confirmed |
| The AI worked with minimal human guidance | Degree of autonomy not validated by Redis or Moonshot AI |
Redis’s public patch record and release notes confirm the underlying flaws are real and have been fixed. What remains self-reported are the specific claims about Kimi K3’s role — the 19-zero-days-in-90-minutes figure, the 27-minute exploit timeline, and the degree of genuine autonomy involved haven’t been independently validated by Redis’s maintainers or by Moonshot AI, the company behind Kimi K3.
Even with that caveat, this isn’t an isolated data point. It follows OpenAI’s own disclosure that its models autonomously breached Hugging Face during a security evaluation, and an earlier case of an autonomous AI tool finding a two-year-old Redis RCE flaw in May. Taken together, these incidents point to the same trend we’ve been tracking across recent agentic AI threat coverage: AI-assisted vulnerability discovery is compressing timelines from weeks to minutes, for defenders and attackers alike.
How to Patch Your Redis Deployment
If you run Redis in production, here’s what to do based on official guidance:
- Check your exact branch version: “Recently patched” isn’t enough — Redis 6.2.22 and 7.4.9 were themselves the May security releases, and both needed another update in July. Confirm the precise version string, not just that you updated recently.
- Upgrade to the fixed release for your branch: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, or 8.8.1, depending on which branch you’re running.
- Restrict the RESTORE command as an interim mitigation: All four disclosed exploit chains require RESTORE. Revoking it from accounts that don’t strictly need it, via Redis ACLs, cuts off both attack paths even before you can upgrade.
- Block untrusted network access to Redis: These are authenticated RCE flaws, meaning a password alone doesn’t fully protect you — network-level access control matters just as much.
- Audit RedisBloom and TDigest usage specifically: If you use the RedisBloom module, prioritize the 8.8.1 update, since that loader was the source of the second exploit chain.
Frequently Asked Questions
What is Kimi K3?
Kimi K3 is a 2.8-trillion-parameter AI model from Moonshot AI, built on a mixture-of-experts architecture, that a security researcher used in a multi-agent configuration to autonomously discover and exploit vulnerabilities in Redis.
Is my Redis server vulnerable right now?
If you’re running stock Redis 6.2.22, 7.4.9, 8.6.4, or 8.8.0 without the July 23 patches, yes. Check your exact version and upgrade to the corresponding fixed release listed in Redis’s official release notes.
Can AI really find zero-day vulnerabilities on its own?
Redis’s confirmed patches prove real vulnerabilities were found and fixed. However, the specific claims about how autonomously Kimi K3 operated, and the exact timing, are self-reported by the researcher and have not been independently verified by Redis or Moonshot AI.
Do I need to do anything if I already patched Redis in May 2026?
Yes. Redis 6.2.22 and 7.4.9 were themselves the May security releases, and both required a further update in July 2026 to fix these newly disclosed issues — being “recently patched” doesn’t guarantee you’re on the current fixed version.
Reported by CyberUpdates365 Desk
Delivering the latest insights on enterprise security, federal AI directives, and the future of IT infrastructure. Follow us for daily updates on how technology is reshaping the corporate landscape.
