Kimi K3 produces 19 exploits in 90 minutes for the latest Redis release

Security researcher Chaofan Shou claims Moonshot AI's Kimi K3 model found 19 previously unknown vulnerabilities in 90 minutes, but public evidence shows two repositories documenting an authenticated remote-code-execution path affecting Redis 8.8.0 via a heap overflow in the TDigest implementation bundled through RedisBloom. Redis 8.8.0 remains the latest tagged release as of July 23rd, with no public advisory for the TDigest issue, and a second repository from Lyutoon indicates the flaw may have been privately reported to Redis on December 29th, 2025.

Chaofan Shou @Fried rice https://x.com/Fried rice , a security researcher who previously built fuzzing systems for browsers and smart contracts, published code on July 23rd that he says turns a flaw in Redis 8.8.0 into remote code execution after Moonshot AI's Kimi K3 model searched the codebase. Shou said in a thread on X https://x.com/Fried rice/status/2080190071102460108 that Kimi K3 https://www.kimi.com/resources/kimi-k3-pricing found 19 previously unknown vulnerabilities in 90 minutes. That count and timeline remain Shou's claims. The public evidence supports a narrower and still consequential finding: two repositories posted on July 23rd describe an authenticated remote-code-execution path affecting Redis 8.8.0, which Redis continues to mark as its latest open-source release. The repository published under berabuddies https://github.com/berabuddies/redis-poc contains proof-of-concept code targeting four Redis versions. Its documentation attributes the Redis 8.8.0 path to a heap overflow in the TDigest implementation bundled through RedisBloom. The repository says an attacker with Redis protocol access and permission to run several default-enabled commands can escalate the memory-corruption flaw into code execution. The same repository documents a separate stream consumer-group double-free affecting Redis 6.2.22, 7.4.9 and 8.6.4. According to its readme, Redis 8.8.0 fixed that earlier bug family, leaving the TDigest flaw as the route used against the newest version. Those are authenticated attack paths, and the exploit's Redis 8.8.0 branch is described as sensitive to the target's memory layout. Instances exposed without authentication would remove the access barrier identified by the researchers. A second repository from Lyutoon https://github.com/Lyutoon/redis-RCE-poc appeared the same day and documents the same RedisBloom TDigest issue against a pinned official Redis container image. Shou acknowledged in his thread that the parallel publication reached the vulnerability first. Lyutoon's repository says an autonomous AI agent found the bug and assembled the exploit chain without manual reverse engineering, though it does not identify that agent as Kimi K3. The second repository also complicates the "zero-day" label. Lyutoon says Redis told the researcher that the underlying vulnerability was originally submitted on December 29th, 2025, with several later reports closed as duplicates. That correspondence is reproduced only through the researcher's account. It indicates that the flaw may have been privately known to Redis months before either public repository appeared, even if users had no public advisory or patch. Redis 8.8.0 remains the latest tagged release Redis released version 8.8.0 https://github.com/redis/redis/releases/tag/8.8.0 on May 25th, 2026. Redis's release page still labels it "Latest" as of July 23rd, and the company's public security advisory list https://github.com/redis/redis/security/advisories does not include an entry for the TDigest issue. Its most recently listed advisories were published on May 5th. The official Redis 8.8 release combined the core server with bundled data structures and modules, including the probabilistic structures supplied by RedisBloom. That packaging broadens the code shipped in the standard distribution. The reported flaw sits in that expanded surface rather than the traditional key-value server core. The exploit repositories do not substantiate Shou's broader total of 19 vulnerabilities. They publicly document two bug families and one code-execution route against Redis 8.8.0. Shou also did not publish a list assigning severity, affected components or exploitability to each of the 19 claimed findings. Shou has been building toward automated vulnerability research The Kimi K3 result follows Shou's earlier work on using coordinated AI agents for vulnerability discovery. In April, he co-authored the AgentFlow preprint https://arxiv.org/abs/2604.20801 , which describes a system that designs multi-agent workflows for security testing. The paper says AgentFlow used Kimi K2.5 while testing Google Chrome and found 10 previously unknown vulnerabilities, including two sandbox escapes later assigned CVE identifiers. Shou's personal site https://scf.so/ says he previously pursued a computer science doctorate at UC Berkeley's Sky Computing Lab and co-founded Fuzzland, where he served as chief technology officer before its acquisition by Solayer. His research record includes program analysis, fuzzing and distributed systems. That background matters to how the Redis result should be read. Kimi K3 did not operate without an experienced security researcher choosing the target, configuring the work and validating the output. The public repositories nevertheless show that AI-assisted security research has moved beyond producing suspicious code snippets. Researchers are publishing complete exploit artifacts on the same day they disclose model-assisted vulnerability sweeps, compressing the interval between finding a memory-safety bug and making it reproducible for anyone who can read Python.