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

The landscape of vulnerability research is evolving rapidly, moving beyond traditional manual analysis to include automated, AI-driven methodologies. This shift was starkly illustrated recently when researchers highlighted a series of critical security flaws in the widely used Redis database. In a striking demonstration of capabilities attributed to Kimi K3 Agents, new zero-day vulnerabilities were identified and weaponized into functional remote code execution exploits. This development underscores a pressing reality for defenders: the time window between discovery and exploitation is shrinking, driven by both human ingenuity and automated agents.

On July 23, the Redis project released a set of seven security updates aimed at addressing these critical memory corruption issues. The research disclosed proof-of-concept exploits targeting specific versions of the software, including 6.2.22, 7.4.9, 8.6.4, and 8.8.0. The exploitation chains identified all leverage the RESTORE command, which is used to create a key from the serialized value returned by DUMP. However, the complexity of the attacks varies across different builds. For the Streams-related exploit chains, the malicious actors require the use of the EVAL command alongside XGROUP to successfully execute the attack. In the case of version 8.8.0, the chain is distinct, relying on EVAL and the bundled RedisBloom module to trigger the underlying memory flaw. While these attacks require authentication, the fundamental memory vulnerabilities pave the way for full remote code execution, allowing an attacker to seize complete control of the server. The vendor has responded by releasing patched versions, specifically 6.2.23, 7.2.15, and 7.4.10, to mitigate the risk.

For security operations teams, the immediate implication is the critical need for patch management, but the nuance lies in the specific conditions required for exploitation. Because these exploits are authenticated, the immediate blast radius is technically limited to users who already possess valid credentials or in scenarios where default credentials are left unchanged. However, Redis instances are frequently exposed in environments where access controls may be lax or where compromise of a web application could provide the necessary authentication token. Security teams must assume that an authenticated user on a Redis instance should be treated as having the potential to gain system-level root access until patches are applied. Furthermore, this incident serves as a wake-up call regarding the RESTORE command. Organizations should review their usage of this specific command and evaluate whether it can be disabled or strictly controlled via rename-command directives in the configuration to reduce the attack surface.

The discovery of these Redis vulnerabilities highlights the double-edged sword of advanced technology, where AI agents can now identify and weaponize flaws at machine speed. Security leaders must prioritize the immediate deployment of the latest Redis updates, specifically moving to versions 6.2.23, 7.2.15, or 7.4.10, to close the door on these remote code execution chains. Beyond patching, it is essential to harden Redis configurations by restricting access to