Kimi K3 Found Redis RCE Zero-Days in 27 Minutes: Patch Now

A swarm of 32 Kimi K3 agents from Moonshot AI autonomously discovered 19 Redis zero-day vulnerabilities in roughly 90 minutes and built a working exploit chain for Redis 8.8.0 in 27 minutes, according to researcher Chaofan Shou. Redis shipped seven security releases on July 23 covering four affected versions—6.2.22, 7.4.9, 8.6.4, and 8.8.0—with public proof-of-concept code now available on GitHub, making patching urgent.

AI agents just did something security researchers have been warning about for years: a swarm of 32 Kimi K3 agents autonomously discovered authenticated remote code execution vulnerabilities in Redis — and reportedly built a working exploit chain for Redis 8.8.0 in 27 minutes. On July 23, Redis shipped seven security releases covering four affected versions. Public proof-of-concept code now exists. The exploit window is open. What Happened Moonshot AI’s Kimi K3 — the 2.8-trillion-parameter model that topped SWE-bench Pro last month — was used in an autonomous multi-agent security research run. Researcher Chaofan Shou reported on X that 32 agents working in parallel found 19 Redis zero-days in roughly 90 minutes, with a full exploit chain for Redis 8.8.0 produced in 27 minutes. Redis’s July 23 advisory https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/ confirms the bugs and the patches, though it does not validate the claimed zero-day count or the degree of agent autonomy. Take the timing as directionally accurate rather than lab-certified. What is not in dispute: authenticated RCE vulnerabilities exist in Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, public PoC code is available on GitHub https://github.com/berabuddies/redis-poc , and Redis has released fixes. That combination is reason enough to treat this as urgent. The Two Bug Classes Both exploit chains share a common entry point: the RESTORE command. Beyond that, they hit different parts of the codebase. Stream NACK double-free affects Redis 6.2.22, 7.4.9, 8.6.4 : In stream consumer groups, a corrupt RDB object can make two consumers point to the same pending-entry record. Removing both consumers frees the same heap chunk twice — a reliable double-free primitive. Exploitation requires authenticated access with RESTORE, EVAL, and XGROUP permissions. CVSS 7.7 High . RedisBloom TDigest heap overflow affects Redis 8.8.0 : The RESTORE command’s RDB loader for the RedisBloom TDigest data structure allocates memory based on one serialized field, then uses a separate attacker-controlled capacity field to decide how much data to load. Classic heap overflow via deserialization. Requires RESTORE, EVAL, and the bundled RedisBloom module. CVSS 7.7 High . Neither bug class has confirmed in-the-wild exploitation as of July 24 — but with public PoCs, that window will not stay open long. Patch Now: What to Upgrade To Redis released fixed versions for all affected branches on July 23: - Redis 6.2.22 → 6.2.23 - Redis 7.4.9 → 7.4.10 - Redis 8.6.4 → 8.6.5 - Redis 8.8.0 → 8.8.1 Check your current version: redis-cli INFO server | grep redis version If you are on Redis Cloud, you are already patched — Redis Inc. applies security updates to managed instances automatically. Valkey deployments are not affected; the codebase diverged from Redis in 2024 and does not share these code paths. If an immediate upgrade is not possible, disable the RESTORE command as a temporary workaround by adding the following to redis.conf: rename-command RESTORE "" Disabling RESTORE breaks RDB-based migration tooling, so assess the impact before applying it in production. Also review ACLs to confirm that only trusted internal services hold EVAL and XGROUP permissions. What the Kimi K3 Story Actually Means The 27-minute headline is eye-catching, but the more important signal is the methodology shift. Prior AI vulnerability research — including Anthropic’s code harness work — largely focused on known vulnerability classes: scanning for patterns that match previously documented bug types. What Kimi K3 reportedly did is different: a multi-agent pipeline that analyzes source code, identifies previously unknown memory corruption paths, and generates working PoC code without a human in the loop. That same capability is now accessible to anyone with API access to Kimi K3. The research community has worried for years about AI compressing the attacker’s timeline; this week is the clearest public demonstration that the compression is real. GuardFall showed shell injection bypassing AI coding agents https://thehackernews.com/2026/07/kimi-k3-agents-found-redis-zero-days.html . Kimi K3 now shows AI finding zero-days in software the rest of us run in production. Neither story suggests the sky is falling. Both suggest that the window between vulnerability existence and exploitation is getting shorter, and that unpatched Redis instances are exactly the kind of target automated offensive tooling goes after first. Action Checklist - Run redis-cli INFO server | grep redis version on every Redis instance - Upgrade to 6.2.23, 7.4.10, 8.6.5, or 8.8.1 depending on your branch - Verify RedisBloom module status on Redis 8.x: redis-cli MODULE LIST - Audit ACLs — restrict RESTORE, EVAL, XGROUP to internal service accounts only - Confirm Redis is not reachable from the public internet - Redis Cloud customers: no action required