-1.png?w=1024)
Finding a serious software vulnerability can take researchers days or weeks. A security team using Moonshot AI’s Kimi K3 said one of its agents found a Redis flaw and built a working remote code execution exploit in just 27 minutes.
The researchers published authenticated proof-of-concept exploits targeting Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0, with both attack paths requiring access to the RESTORE command. Redis issued seven security updates on July 23 to address the underlying memory-corruption flaws. The findings show how quickly AI agents can move from reviewing source code to building usable exploit chains. Defenders could have less time to verify patches, restrict high-risk commands, and reduce exposure once technical details become public.
How the Redis exploit chains worked
The Hacker News reported that the first attack path involved a shared-ownership flaw in Redis Streams. A corrupted database object could make two consumers point to the same pending-entry record, causing Redis to free the same memory object twice when both consumers were removed.
The second path affected the RedisBloom TDigest loader. The loader allocated memory using one serialized value but trusted a separate attacker-controlled capacity field when deciding how much data to load, creating an out-of-bounds write.
The published scripts were designed to turn the resulting memory errors into arbitrary read-and-write access, leak Redis and system-library addresses, and eventually execute system commands. Some chains also required permission to use EVAL, XGROUP, or the RedisBloom module.
Redis released fixed versions across supported branches, including 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, and 8.8.1. Neither Redis’ July 23 release notes nor the public proof-of-concept repositories reported exploitation in the wild as of July 24.
The limits of the 27-minute claim
CyberPress said that the Kimi K3 agent cloned the Redis source code, fuzzed selected functions, and used the GDB debugger to investigate crashes with limited human guidance.
The publication linked the speed of the research to Kimi K3’s mixture-of-experts architecture, long context window, and ability to work with development tools. Moonshot AI, the China-based company behind the model, developed Kimi K3 for general and large-scale agentic workloads.
The reported 27-minute exploit-development time and a separate claim that Kimi K3 agents found 19 Redis zero-days in about 90 minutes remain self-reported. Redis confirmed the underlying flaws and released fixes, but its public disclosures did not verify how independently the agents worked or validate the claimed number of discoveries.
Stingrai also cautioned against combining the latest findings with five Redis vulnerabilities patched in May. Redis credited those earlier flaws to named human researchers, making the Kimi K3 disclosure a related but separate case of AI-assisted security research.
What security teams should review now
Organizations running self-managed Redis should verify the exact version and branch deployed in production. Redis 6.2.22 and 7.4.9 were themselves security updates released in May, showing that being recently patched does not necessarily mean a system is protected from newly disclosed flaws.
Administrators who cannot upgrade immediately should revoke RESTORE access from accounts that do not require it, audit authenticated users, block untrusted network access, and check whether RedisBloom is installed.
The findings also put more attention on Moonshot AI, one of the Chinese companies pushing to make powerful agent systems cheaper and more widely available. Kimi K3’s performance shows how that competition could influence not only enterprise AI adoption, but also the speed of vulnerability research and exploit development.
Read More: How Moonshot AI’s Kimi K3 could reshape enterprise AI competition.