Kimi K3 AI Agent Uncovers New Redis Streams Flaw and Chains Known RCE Bugs

Moonshot AI's newly released Kimi K3, a 2.8 trillion parameter mixture of experts model, has demonstrated the growing offensive capability of autonomous AI agents.

Security researcher Chaofan Shou reported that Kimi K3 agents coordinating up to 32 subagents found 19 candidate zero-day vulnerabilities in Redis 8.8.0 in roughly 90 minutes, then built a working authenticated remote code execution proof of concept for one of them in just 27 minutes. Those figures are self-reported by a single researcher and have not been independently verified. Redis has confirmed the underlying flaws exist and has issued fixes, but has not validated the specific "19 zero-days" count or the degree of autonomy claimed.

A capable, cheap model built for agentic work

Kimi K3 ships in two variants, K3 Max for general agentic workloads and K3 Swarm Max for large scale parallel processing. It is built on a sparse mixture of experts architecture that routes each token through 16 of 896 experts, supported by a 1 million token context window.

Its API pricing, 3 dollars per million input tokens and 15 dollars per million output tokens, undercuts most Western frontier models at comparable capability, with open weights scheduled for public release under a Modified MIT licence.

That combination of scale, long context reasoning and low cost appears to have let the agent autonomously clone Redis source code, generate fuzzers, instrument the software and debug crashes using GDB with minimal human guidance beyond a simple prompt. The researcher published the findings as non destructive proofs of concept on GitHub, describing the work as authorised security research.

What was found, and what is still unconfirmed

The published proof of concept targets Redis versions 6.2.22, 7.4.9, 8.6.4 and 8.8.0, and the new Streams shared NACK issue behind the 27 minute exploit is a bug class serious enough to produce a working exploit chain but one that Redis's own July release notes have not yet assigned a CVE or CVSS score to. It currently has no matching entry in the National Vulnerability Database or CISA's Known Exploited Vulnerabilities catalogue.

Some exploit toolkit writeups have labelled this new Streams issue as part of CVE-2026-25589 and attached a CVSS 9.8 rating, but that mapping does not check out. CVE-2026-25589 is a separate, earlier identifier that Redis and NVD both attribute to a heap based buffer overflow in the RedisBloom module, with an official base CVSS score of 7.7, not 9.8.

In that flaw, unvalidated serialised values processed through the RESTORE command can trigger invalid memory access and potential remote code execution for an authenticated attacker with RESTORE permissions. It was patched in RedisBloom 2.8.20. Redis issued seven security updates in total on 23 July 2026 to address this cluster of use after free and invalid memory access bugs across Redis OSS, Redis Software and Redis Cloud.

All of the disclosed exploit chains require an authenticated session with access to specific commands. None are unauthenticated or pre auth.

The same capability cuts both ways

Researchers have been direct about the dual nature of this finding. For a B2B security audience, the practical read is:

• The same agentic capability that compresses vulnerability discovery from weeks to minutes could just as easily be weaponised by threat actors against unpatched Redis deployments still running in production.
• This has prompted calls for researchers using autonomous agents to notify vendors directly before publishing exploit chains, since the underlying technique itself becomes a roadmap the moment it is public, even when proofs of concept are designed to be non destructive.
• Google's CodeMender represents the defensive mirror image of this, an AI agent explicitly built to find, verify and patch vulnerabilities before they reach production.
• Kimi K3's discovery is effectively the same underlying capability applied without that specific safety framing. The technology itself does not favour defenders over attackers, it favours whoever deploys it first against a given target.

What enterprises running Redis should do

Organisations running Redis or RedisBloom should patch to the fixed releases immediately given the severity of the confirmed CVEs and the public availability of proof of concept exploit chains.

Beyond patching, security teams should restrict RESTORE command access through ACL rules and audit authenticated user privileges directly. Several of the disclosed flaws require only authenticated access rather than a fully unauthenticated attack path, meaning credential hygiene and least privilege access controls meaningfully reduce exposure even before a patch is applied.

Given how quickly AI driven tooling is now finding vulnerabilities in widely deployed infrastructure, and given that the newest Streams finding still has no formal CVE assignment, enterprise security teams should treat this as a broader signal. Patch management cycles and threat monitoring for open source components generally should accelerate, rather than waiting for a CVE number before acting on credible proof of concept evidence.