Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say

# AI Agents Cracked Redis Open: Kimi K3 Found the Zero-Days, Then Built the Exploits

## The Threat

Redis spent July 23 shipping seven simultaneous security releases after researchers demonstrated what happens when you hand an AI agent system access to a database codebase and tell it to find bugs: it finds them, then builds working exploits. The Kimi K3 agent system uncovered two independent memory corruption chains in Redis — one in the Streams subsystem, one buried in the bundled RedisBloom module — and published authenticated remote code execution proof-of-concepts against Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0.

Both attack paths flow through the RESTORE command, which lets clients deserialize arbitrary RDB objects directly into a running Redis instance. The Streams chain exploits a shared-ownership flaw: a crafted RDB object can cause two consumers to reference the same pending-entry (streamNACK) record. Removing the first consumer frees the object; the second consumer holds a dangling pointer. Removing it triggers a double-free, which the published exploit chains into arbitrary memory access and ultimately a system() call. The RedisBloom path is an out-of-bounds write in the TDigest RDB loader — the loader allocated centroid arrays based on a serialized compression value, but trusted a separate, attacker-controlled capacity field when deciding how many nodes to read. Paired with a small real allocation, an inflated metadata field writes past the buffer end; the Redis 8.8.0 exploit turns that into read/write primitives, leaks Redis and libc addresses, and poisons a database hash function so a crafted GET drops into system().

Neither path has been observed in the wild as of July 24, 2026. But that's cold comfort: working PoC code is now public, both chains require only authenticated access rather than admin privileges, and one of the vulnerable releases — Redis 8.6.4 — was itself a May security update that Redis told users to install. The shared-NACK guard that actually fixes the Streams bug appears in 8.6.5, not 8.6.4, despite the 8.6.4 release notes citing the relevant pull request.

## Severity and Impact

| Field | Streams (Shared-NACK) | RedisBloom TDigest |

|---|---|---|

| CVE | CVE-2026-25589 (disputed mapping) | CVE-2026-25589 (Redis-assigned) |

| CWE | CWE-415 (Double Free) / CWE-416 (Use After Free) | CWE-787 (Out-of-Bounds Write) |

| CVSS Score | Not officially assigned | Not officially assigned |

| Attack Vector | Network | Network |

| Attack Complexity | High (crafted RDB required) | High (crafted RDB required) |

| Privileges Required | Low (RESTORE permission) | Low (RESTORE + RedisBloom module) |

| User Interaction | None | None |

| Scope | Unchanged | Unchanged |

| Impact | RCE via arbitrary memory access | RCE via OOB write and libc leak |

> Note: Redis's July 23 release notes list no CVE number or CVSS score for either vulnerability. The PoC repositories reference CVE-2026-25589 as an "incomplete fix family" for the Streams issue, but Redis maps that CVE to the RedisBloom memory corruption. Expect updated CVE records and official CVSS scores to follow.

## Affected Products

Streams shared-NACK use-after-free (double-free → RCE):

RedisBloom TDigest out-of-bounds write (→ RCE):

Fixed releases by branch:

## Mitigations

Immediate actions:

For deployments using RedisBloom / TDigest:

Detection:

## References

---

## HackWire Analysis

The headline here isn't the Redis bugs themselves — memory corruption in a deserialization path is a familiar story. The headline is that an AI agent system found them and built working exploit chains, and that timeline is compressing in a way the industry hasn't fully processed yet.

Kimi K3 operating as an autonomous research agent represents a qualitative shift from prior AI-assisted vuln discovery. Earlier AI security tools flagged suspicious patterns for human review. This is different: an agent system audited a codebase, identified novel memory safety flaws, and produced authenticated RCE proof-of-concepts ready to fire against production software. The time between "model runs" and "exploit ships" is now measured in hours, not months.

That acceleration makes the incomplete-fix problem especially dangerous. Redis told users in May that 6.2.22 and 7.4.9 were their secure releases. They were wrong — the shared-NACK ownership guard wasn't in either of them. Organizations that dutifully patched in May are still exposed. This is a pattern worth watching: as vendors rush to ship fixes under AI-accelerated disclosure pressure, incomplete patches will become more common, not less. Defenders need to verify the actual code change landed, not just that the version number incremented.

The mitigation here is unusually tractable. Revoking RESTORE from non-essential accounts cuts off both chains immediately. Most production Redis deployments don't use RESTORE at all — it's a replication and backup utility. If your application code touches RESTORE, you're either running RDB imports or something has gone wrong. Audit that permission now, patch tonight, and treat any account holding RESTORE plus EVAL as a high-value target for monitoring regardless.

The deeper question for the industry: how do you maintain a responsible disclosure process when the researcher is a software agent that can ship a PoC the same afternoon it finds the bug?

— HackWire Editorial

---

## Related Coverage